Re: panic during fdisk'ing a md(4) device
Hi, Hmm. I used an old set of patches to avoid filtering out local changes again. Try the enclosed up to date patches. Hmmm. Fresh -current, fresh patch. (Hunk 2 still doesnt apply cleanly, but this seems to be irrelevant for the problem) Old symptom: ... mounting root from ufs:/dev/ad0s3a Fatal Trap 12: page fault while in kernel mode fault virt. addr. = 0x20 fault code = superv. read, page not present IP = 0x8:0xc0176b61 SP = 0x10:0xc03d6b7c FP = 0x10:0xc03d6b8c CS = base 0x0, limit 0x, type 0x1b DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 curproc = 0 (swapper) Can I get from kernel.debug and the IP-address the faulting code postmortem for shure? `nm /boot/kernel~/kernel | grep c0176b` gives: c0176b4c T dsname c0176bf8 T dsopen Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
kld question
I made a kernel module that logs execve system calls by intercepting the execve syscall, log it and then execute the original syscall. This was pretty straightforward to do, and it works beautifully on STABLE, but on CURRENT it bombs on this line: uid = p-p_cred-pc_ucred-cr_uid; So, my question: how does one obtain the UID from the proc struct in CURRENT? Preferably in a way that will both work on CURRENT and STABLE. Cheers, Emiel -- I'm proud to be paying taxes in the United States. The only thing is -- I could be just as proud for half the money. -- Arthur Godfrey To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: kld question
On 10-Jan-02 Emiel Kollof wrote: I made a kernel module that logs execve system calls by intercepting the execve syscall, log it and then execute the original syscall. This was pretty straightforward to do, and it works beautifully on STABLE, but on CURRENT it bombs on this line: uid = p-p_cred-pc_ucred-cr_uid; So, my question: how does one obtain the UID from the proc struct in CURRENT? Preferably in a way that will both work on CURRENT and STABLE. p-p_ucred-cr_uid right now, but it will change before too long. :) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: module build process changed
I've recently committed a series of changes which affect the way modules are built. Since I can't test *every* module, please let me know immediately if you run into problems with modules refusing to load due to undefined symbols, or not working quite right. I've tried hard to make sure it's all correct, but bugs and errors are inevitable. Some overview of what this achieves: Previously, there have been two symbol namespaces in the kernel; the global symbols namespace and the per-source-file namespace. To build a module with more than one source file, one typically had to expose some symbols to the global namespace, risking accidental collisions with other modules. The common workaround for this has been to prefix all exported symbols with a few characters identifying the module, but as we accumulate more modules, this mechanism is becoming less reliable. In order to deal with this problem, I have changed the module build process so that symbols global to the module are converted to local symbols when the module is linked into the .kld/,ko file. In order to allow modules that intentionally export symbols to continue to do so, a new module makefile variable 'EXPORT_SYMS' has been implemented. This variable may take three values; YES will revert to the traditional behaviour of exporting all globals. It should typically only be used when converting a module from 4.x, or to quickly verify that a problem is due to a failure to export a symbol. A list of symbol names may be given, and these symbols will be exported. And thirdly, the name of a file may be given, and this file will be read for the list of symbols to export. Note that it is not an error to list a symbol not found in the module object. This allows modules to be built with different options without requiring different export lists. Looking to the near future, this technique will be extended to the building of monolithic kernels as well. The .kld files generated during a module build can be linked with a monolithic kernel, and thus much of the duplicate building of kernel source can be eliminated. Once this conversion is complete, the per-module namespace will behave consistently within the kernel as well. Questions and comments welcome. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: module build process changed
* Mike Smith [EMAIL PROTECTED] [020110 17:36] wrote: Questions and comments welcome. Looks really cool, nice job. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: module build process changed
Mike Smith wrote: In order to deal with this problem, I have changed the module build process so that symbols global to the module are converted to local symbols when the module is linked into the .kld/,ko file. In order to allow modules that intentionally export symbols to continue to do so, a new module makefile variable 'EXPORT_SYMS' has been implemented. This variable may take three values; YES will revert to the traditional behaviour of exporting all globals. It should typically only be used when converting a module from 4.x, or to quickly verify that a problem is due to a failure to export a symbol. A list of symbol names may be given, and these symbols will be exported. And thirdly, the name of a file may be given, and this file will be read for the list of symbols to export. [ ... ] Questions and comments welcome. In the book Writing Linux DEvice Drivers, there is a neat bit on how Linux does this. Effectively, they export all symbols within the module load if there is no explicit symbol table export call, and they export only the symbols that are requested, if there is. The way this works is that they substitute the symbol list at the module load time, after the load, but before the relocation. This is actually nicer, in that it leaves the symol list control in the source file, rather than hiding it in the Makefile. In addition, they have a moderately nify approach in that they as a major/minor/minor version mask to each one, and then exporte the version number (it seems they don't know how to work linker sets and sections quite right yet, or they would not need to be as careful to avoid multiple declaration of the verstion value). The version is the version of the module header files -- which is basically the version that the module was compiled on -- and you can mask them for interfaces that don't vary widely over time (e.g. memcpy()), so that binary modules tend to work more widely across Linux kernel versions. There is an example in the book of old (2.0.x) vs. new (2.1.x) modules, with how to write one that's portable between both versions. I rather like that all you have to do is use an EXPORT_SYM() macro, and nothing has to be declared static... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: module build process changed
In the book Writing Linux DEvice Drivers, there is a neat bit on how Linux does this. Effectively, they export all symbols within the module load if there is no explicit symbol table export call, and they export only the symbols that are requested, if there is. I considered this approach, but couldn't work out a tidy way of making it work for the case where the module is statically compiled into the kernel. Effectively, you'd have to parse the linker set out of the .kld file, then feed it to objcopy to localise the symbols before linking. There's no reason that, presuming a mechanism like this was devised, we couldn't dispense with the EXPORT_SYMS declaration and generate the list automatically, of course. I'd be happier with something like __attribute__((__export__)) on the declaration, of course. I'm also not fond of the default to export all symbols approach, but that's just a detail. Regards, Mike To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
