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

From: John Baldwin <jhb_at_freebsd.org>
Date: Tue, 9 Nov 2010 08:44:28 -0500
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.

-- 
John Baldwin
Received on Tue Nov 09 2010 - 12:48:48 UTC

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