Re: kldunload(8) returns 0, although it fail

From: John Baldwin <jhb_at_freebsd.org>
Date: Wed, 17 Nov 2010 10:06:10 -0500
On Tuesday, November 16, 2010 10:20:12 pm Alexander Best wrote:
> On Wed Nov 10 10, John Baldwin wrote:
> > 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_at_, but nobody could help me with it.
> > > > > > > > to me this looks like a bug, so i assume posting it again here on
> > > > > > > > freebsd-current_at_ 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.
> 
> sorry it took me a while to check this out. i did some more research and it
> seems a few things are broken:
> 
> 1) i have snd_hda in my loader.conf which will load sound as a dependency.
> unloading snd_hda should then automatically unload sound, which it *doesn't*.
> i need to unload sound manually.

I clearly said earlier that this is what happens.  It's the paragraph below
where I said that the kernel has no idea when it discovers the modules that
the loader loaded which ones were explicit and which ones were implicit.  It
treats them all as explicit.
> 
> 2) if i unload all ng_* modules i should then be able to also unload netgraph,
> because no dependencies are left. however kldunload fails with EBUSY!

Perhaps netgraph.ko is not unloadable in general?  Actually, that is exactly what
it does:

	case MOD_UNLOAD:
		/* You can't unload it because an interface may be using it. */
		error = EBUSY;
		break;

(from ng_base.c).

> > 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
Received on Wed Nov 17 2010 - 14:08:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC