From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 19 04:51:13 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 ABBDE16A4CE; Mon, 19 Jul 2004 04:51:13 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6659843D55; Mon, 19 Jul 2004 04:51:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-68-121-219-69.dsl.snfc21.pacbell.net [68.121.219.69])i6J4pAlM139060; Mon, 19 Jul 2004 00:51:10 -0400 Message-ID: <40FB533D.2080208@elischer.org> Date: Sun, 18 Jul 2004 21:51:09 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org cc: Gleb Smirnoff 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:51:13 -0000 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 , 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" >> >> >> > >_______________________________________________ >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" > >