From owner-freebsd-current@FreeBSD.ORG Wed Nov 10 22:26:50 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 812EF1065674; Wed, 10 Nov 2010 22:26:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 51ABC8FC19; Wed, 10 Nov 2010 22:26:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 046F646B06; Wed, 10 Nov 2010 17:26:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EF81D8A009; Wed, 10 Nov 2010 17:26:48 -0500 (EST) From: John Baldwin To: Alexander Best Date: Wed, 10 Nov 2010 17:17:50 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <20101109114612.GA58585@freebsd.org> <20101110215839.GA74943@freebsd.org> <20101110220721.GA76154@freebsd.org> In-Reply-To: <20101110220721.GA76154@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011101717.51062.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Wed, 10 Nov 2010 17:26:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: kldunload(8) returns 0, although it fail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:26:50 -0000 On Wednesday, November 10, 2010 5:07:21 pm Alexander Best wrote: > On Wed Nov 10 10, Alexander Best wrote: > > On Tue Nov 9 10, John Baldwin wrote: > > > On Tuesday, November 09, 2010 9:10:28 am Alexander Best wrote: > > > > On Tue Nov 9 10, John Baldwin wrote: > > > > > On Tuesday, November 09, 2010 6:46:12 am Alexander Best wrote: > > > > > > hi there, > > > > > > > > > > > > i posted this message on freebsd-questions@, but nobody could help me with it. > > > > > > to me this looks like a bug, so i assume posting it again here on > > > > > > freebsd-current@ might be better. > > > > > > > > > > > > please keep in mind that the issue here is not the fact that the second attempt > > > > > > to unload sound.ko/netgraph.ko fails. it *should* fail, because both modules > > > > > > have dependencies. however it should fail with the first attempt. right now > > > > > > kldunloadf() returns zero, whereas it should actually return EBUSY (just like > > > > > > the second attempt). > > > > > > > > > > > > i've attached two kdump outputs: one for the first 'kldunload' attempt and one > > > > > > for the second. as you can see the problem is that for some reason kldunloadf() > > > > > > returns zero, although it couldn't unload the module. > > > > > > > > > > Did you get an error message in dmesg? If you have manually loaded > > > > > netgraph.ko (via netgraph_load="YES" in loader.conf or an explicit kldload) > > > > > and then loaded other modules that depend on it (such as ng_foo.ko) then this > > > > > is expected behavior. What your kldunload has done is to remove the manual > > > > > reference from loader.conf or 'kldload netgraph.ko'. What this changes is what > > > > > happens when you do 'kldunload ng_foo.ko'. If you unload ng_foo.ko now, then > > > > > netgraph.ko will also be unloaded when its last reference drops (in this case > > > > > it looks like you actually have two ng_*.ko objects loaded, so you would have > > > > > to unload both of them, but I will assume a single ng_foo.ko to make the > > > > > explanation simpler). If you had not done 'kldunload netgraph.ko' but had > > > > > done 'kldunload ng_foo.ko', then the manual reference would have kept netgraph.ko > > > > > loaded. > > > > > > > > > > All this logic exists so that if you do 'kldload foo.ko' and it auto-loads bar.ko > > > > > as a dependency, then doing 'kldunload bar.ko' will unload both foo.ko and bar.ko. > > > > > > > > i have ng_ubt_load="YES" in my loader.conf and kldstat says: > > > > > > > > Id Refs Address Size Name > > > > 1 37 0xffffffff80100000 a2ddb8 kernel > > > > 2 1 0xffffffff80b2e000 295e8 snd_hda.ko > > > > 3 1 0xffffffff80b58000 85110 sound.ko > > > > 4 1 0xffffffff80bde000 cf79e0 nvidia.ko > > > > 5 5 0xffffffff818d6000 418c0 linux.ko > > > > 6 1 0xffffffff81918000 80e8 ng_ubt.ko > > > > 7 2 0xffffffff81921000 fa78 ng_hci.ko > > > > 8 2 0xffffffff81931000 2bd0 ng_bluetooth.ko > > > > 9 3 0xffffffff81934000 15e68 netgraph.ko > > > > 10 1 0xffffffff81a12000 3efb linprocfs.ko > > > > 11 3 0xffffffff81a16000 4698 pseudofs.ko > > > > 12 1 0xffffffff81a1b000 31b3 procfs.ko > > > > 13 1 0xffffffff81a1f000 a37 linsysfs.ko > > > > 14 1 0xffffffff81a20000 6f4 rtc.ko > > > > > > > > also the same happens with sound.ko. i have snd_hda_load="yes". and i think > > > > snd_hda is the only dependecy for sound.ko. > > > > > > > > there was no error message in dmesg for the first kldunload attempt. > > > > > > > > i think i understand the logic, however the current behavior does not confirm > > > > to the description in kldunload(2). > > > > > > Hmm, ok, fair enough. Do you get the same behavior if you kldload ng_ubt.ko > > > after boot? > > just tested and the behavior is *not* the same. when i do kldload ng_ubt after > boot everything seems fine. netgraph gets loaded and has a REF count of 2. if i > try doing `kldunload netgraph` i get EBUSY the first time i run that command. > when i add ng_ubt_load=yes to /boot/loader.conf kldstat reports a REF count of > 3 for netgraph.ko and i get the behavior i described beforehand. Try doing 'kldload netgraph.ko' and then 'kldload ng_ubt.ko' (along with manually loading any other netgraph modules so that nothing is loaded magically as a dependency) and see what behavior that gives you. When you load modules from the loader, they and all their dependencies are treated as if you had manually loaded them similar to kldload. This because the kernel can't determine which modules loaded by the loader were silent dependencies. -- John Baldwin