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

[Gleb Smirnoff]

On Sun, Jul 18, 2004 at 09:51:09PM -0700, Julian Elischer wrote:
J> >> there is problem when linker_load_module() is called from a kernel
J> >>thread with no associated user process, and it asks to load module by
J> >>name, not by filename.  With such parameters it requires looking through
J> >>device.hints file.  And vn_open() assumes that
J> >>ndp->ni_cnd->cn_thread->td_proc is valid. 
J> >>
J> >>Any ideas how to solve this?
J> >>   
J> >>
J> >
J> >Generally speaking, attempting to perform file I/O from an interrupt
J> >thread or software interrupt is a really bad idea.  There are a number of
J> >reasons this is the case, not least that lookups and file operations occur
J> >in the context of a process with a root directory, current working
J> >directory, etc, and that a network swi or ithread doesn't have said
J> >context (and may execute before that's available).  Also, stalling the
J> >netisr or an ithread on disk I/O seems to be a bad idea as well, not to
J> >mention the NFS root file system case.  So the question would seem to be
J> >"Can we avoid it entirely?".  I'm not quite sure what the answer here is,
J> >but most similar cases I know of involve an asynchronous upcall message to
J> >user space to load the module, or it being pushed from user space to
J> >kernel without an upcall.  Vis., devd loading a module in response to a
J> >device event, etc.  Adopting something more like that would help to avoid
J> >this situation.  I've seen similar reports a couple of times in the past,
J> >and each time it worries me :-).
J> > 
J> >
J> Probably the onl thing to do is to refuse to try an load the modules if 
J> you are not running
J> in the context of a process..
J> the question is:
J> 
J> "What were you doing when this happenned?"

Run mpd as PPPoE server. Ensure that ng_tee is not loaded, yet. Connect
to this server.
I have hit this panic with ngctl also, but can't remember hot to reproduce it.

What is the correct way to determine whether we are in interrupt thread or
not?

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE