[RFC] kldunload -f argument.

[Poul-Henning Kamp]

In an ideal situation, unmount(8) will fail to unload if the
filesystem is in use but the administrator has the option of applying
the -f(orce) option which tells the kernel: "umount at any cost" [3].


We do not have the same flexibility with kldunload(8), and this is
leading to a minor spot of trouble for modules which autoattach to
things, like for instance GEOM classes where it can be very hard if
not impossible to get the module idle from userland so it can be
unloaded.

The society of archtecturally confused kernel hackers had a brief
discussion about this on that IRC channel tonight (UTC) and the
following proposal was what came out of it.

Kldunload today sends only one event to the modules:  MOD_UNLOAD and
if the module returns non-zero, it gives up.  Most modules will
return non-zero for any minor or major bump in the road.

In the new world order, a new event is introduced MOD_QUIESCE[1].

A normal kldunload will send a MOD_QUIESCE and if it returns non-zero
the kldunload fails.  If MOD_QUIESCE succeeds, MOD_UNLOAD is sent.
If MOD_UNLOAD comes back non-zero, the kldunload fails.

A forced kldunload is the same, except the return value from
MOD_QUIESCE is ignored.

The "in-use" checks in the module should happen in the MOD_QUIESCE
event and if the module decides to return success it should 
refuse any new service [4] knowing that MOD_UNLOAD will be following.

Modules should now only veto MOD_UNLOAD if there is no way to unload
the module without the unload endangering the kernel[2].  Reasons
could be memory in the module used by bits of the kernel where it
can't be reclaimed.  Root filesystem mounted using filesystem in
module etc.

Today most modules will return EOPNOTSUPP or zero for an unknown
MOD_FOO event, so backwards compatibility is a minor issue.

Comments ?

Poul-Henning



[1] I hate that name, I can't spell it without looking it up.  Better
suggestions are very welcome.

[2] Note that this does not include secondary effects:  The fact
that filesystem with insufficient error checks explode if its disk
driver is unloaded is NOT a valid reason for the disk driver to
refuse unloading: the filesystem should be fixed instead.

[3] We are not at this point interested in discussing how many bugs
there are in this and related code and how many ways you can explode
your system using unmount -f.  We know.  We'll get to it.  Eventually.

[4] This is necessary to close the obvious race wher a MOD_UNLOAD
preventing auto attachment happened between MOD_QUIESCE and MOD_UNLOAD.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.