From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 04:39:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0711216A4CE; Mon, 19 Jul 2004 04:39:07 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9349143D54; Mon, 19 Jul 2004 04:39:07 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i6J4cbEM042745; Mon, 19 Jul 2004 00:38:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i6J4cbO5042742; Mon, 19 Jul 2004 00:38:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 19 Jul 2004 00:38:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20040717122147.GC34801@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: linker_load_module(NULL, "modname", ...) from thread with no user process X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2004 04:39:08 -0000 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 , 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" >