linker_load_module(NULL, "modname", ...) from thread with no user process

[Julian Elischer]

Robert Watson wrote:

>On 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 :-).
>  
>
Probably the onl thing to do is to refuse to try an load the modules if 
you are not running
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
>>_______________________________________________
>>freebsd-hackers at freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>
>>    
>>
>
>_______________________________________________
>freebsd-hackers at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>  
>