Robert Watson wrote:
Probably the onl thing to do is to refuse to try an load the modules if you are not runningOn Sat, 17 Jul 2004, Gleb Smirnoff wrote:
there is problem when linker_load_module() is called from a kernel
thread with no associated user process, and it asks to load module by
name, not by filename. With such parameters it requires looking through
device.hints file. And vn_open() assumes that
ndp->ni_cnd->cn_thread->td_proc is valid.
Any ideas how to solve this?
Generally speaking, attempting to perform file I/O from an interrupt
thread or software interrupt is a really bad idea. There are a number of
reasons this is the case, not least that lookups and file operations occur
in the context of a process with a root directory, current working
directory, etc, and that a network swi or ithread doesn't have said
context (and may execute before that's available). Also, stalling the
netisr or an ithread on disk I/O seems to be a bad idea as well, not to
mention the NFS root file system case. So the question would seem to be
"Can we avoid it entirely?". I'm not quite sure what the answer here is,
but most similar cases I know of involve an asynchronous upcall message to
user space to load the module, or it being pushed from user space to
kernel without an upcall. Vis., devd loading a module in response to a
device event, etc. Adopting something more like that would help to avoid
this situation. I've seen similar reports a couple of times in the past,
and each time it worries me :-).
in the context of a process..
the question is:
"What were you doing when this happenned?"
Here is a sample backtrace:
[...] #21 0xc1b4fa2b in ngintr () from /boot/kernel/netgraph.ko #22 0xc05e236a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:255 #23 0xc0554d22 in ithread_loop (arg=0xc14f5400) at /usr/src/sys/kern/kern_intr.c:544 #24 0xc0553dd2 in fork_exit (callout=0xc0554ba0 <ithread_loop>, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:816
-- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
