Date: Mon, 19 Jul 2004 00:38:37 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: hackers@freebsd.org Subject: Re: linker_load_module(NULL, "modname", ...) from thread with no user process Message-ID: <Pine.NEB.3.96L.1040719003147.37108w-100000@fledge.watson.org> In-Reply-To: <20040717122147.GC34801@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-).
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Principal Research Scientist, McAfee Research
>
> Here is a sample backtrace:
>
> #8 0xc06ba0b3 in trap (frame=
> {tf_fs = -1946419176, tf_es = 2106261520, tf_ds = 607387664, tf_edi = -877233464, tf_esi = -1066365186, tf_ebp = -877234268, tf_isp = -877234312, tf_ebx = 2065, tf_edx = -877233504, tf_ecx = 0, tf_eax = -1051754144, tf_trapno = 12, tf_err = 0, tf_eip = -1068097648, tf_cs = 8, tf_eflags = 66182, tf_esp = -1056682528, tf_ss = 0})
> at /usr/src/sys/i386/i386/trap.c:417
> #9 0xc0561f90 in _mtx_lock_flags (m=0x0, opts=0,
> file=0xc0708efe "/usr/src/sys/kern/vfs_subr.c", line=2065)
> at /usr/src/sys/kern/kern_mutex.c:247
> #10 0xc05c989c in vref (vp=0x811) at /usr/src/sys/kern/vfs_subr.c:2065
> #11 0xc05c2438 in namei (ndp=0xcbb67aa0) at /usr/src/sys/kern/vfs_lookup.c:161
> #12 0xc05d4f63 in vn_open_cred (ndp=0xcbb67aa0, flagp=0xcbb6797c, cmode=0,
> cred=0xc14eae80, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:191
> #13 0xc05d4cf3 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0)
> at /usr/src/sys/kern/vfs_vnops.c:91
> #14 0xc055ddc3 in linker_hints_lookup (
> path=0xc074d160 "/boot/kernel;/boot/kernel;/boot/modules", pathlen=12,
> modname=0xcbb67b68 "ng_tee", modnamelen=6, verinfo=0x0)
> at /usr/src/sys/kern/kern_linker.c:1474
> #15 0xc055e2da in linker_search_module (modname=0xcbb67b68 "ng_tee", modnamelen=6,
> verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1594
> #16 0xc055e49b in linker_load_module (kldname=0x0, modname=0xcbb67b68 "ng_tee",
> parent=0x0, verinfo=0x0, lfpp=0xcbb67b64)
> at /usr/src/sys/kern/kern_linker.c:1683
> #17 0xc1b49aa6 in ng_make_node () from /boot/kernel/netgraph.ko
> #18 0xc1b4bb61 in ng_mkpeer () from /boot/kernel/netgraph.ko
> #19 0xc1b4d9b1 in ng_generic_msg () from /boot/kernel/netgraph.ko
> #20 0xc1b4d615 in ng_apply_item () from /boot/kernel/netgraph.ko
> #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@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040719003147.37108w-100000>