Date: Thu, 08 Jul 2004 22:12:28 +0200 From: Poul-Henning Kamp <phk@phk.freebsd.dk> To: arch@freebsd.org Subject: [RFC] kldunload -f argument. Message-ID: <6595.1089317548@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6595.1089317548>