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

From: Gleb Smirnoff (glebius_at_freebsd.org)
Date: 07/19/04

  • Next message: Gleb Smirnoff: "Re: linker_load_module(NULL, "modname", ...) from thread with no user process" 
    Date: Mon, 19 Jul 2004 11:23:51 +0400
To: Julian Elischer <julian@elischer.org>

    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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Gleb Smirnoff: "Re: linker_load_module(NULL, "modname", ...) from thread with no user process"

    Relevant Pages

    • Re: Questions regarding Synchronisation in Windows (Spinlocks)
      ... Vista/Longhorn now only ship multiprocessor kernel. ... Interrupts are handled in context of ISR. ... Since Spinlocks execute at DPC/Dispatch level, there is no way for the ... But an interrupt occurs which has an IRQL> DPC Dispatch level OR the ...
      (microsoft.public.win32.programmer.kernel)
    • Re: linux context switching
      ... the process is excuted in a kernel mode, at this momnet is there context ... all registers are saved on the stack. ... interrupt handler is excuted ...
      (comp.os.linux.development.system)
    • Re: Why cant we sleep in an ISR?
      ... interrupt is not associated with any context in the first place. ... includes the kernel and userspace stack pointers, the register set, ... this, an interrupt, depending on the version of your kernel and arch, ...
      (Linux-Kernel)
    • Fwd: request_module() fails
      ... I'm trying to load some modules upon occurance of a GPIO interrupt. ... Inside the tasklet, I call request_module to load a driver. ... kernel name>. ...
      (Linux-Kernel)
    • linux context switching
      ... In linux, is there kernel context? ... a user process is having CPU ... H/W interrupt occurs ...
      (comp.os.linux.development.system)