Daniel Phillips wrote:
> > But you've rather cutely arranged that these kinds of mount _do_
> > disappear when the last file being used on them disappears. Clever, if
> > a bit disturbing.
>
> And it's not a good way to drive module unloading. It is rmmod that
> should cause a module to be unloaded, not close. The final close
> *allows* the module to be unloaded, it does not *cause* it to be. So
> to get the expected behaviour, you have to lather on some other fanciful
> construction to garbage collect modules ready to be unloaded, or to let
> rmmod inquire the state of the module in the process of attempting to
> unload it, and not trigger the nasty races we've discussed. Enter
> fancy locking regime that 3 people in the world actually understand.
Eh? In this case, Al Viro's scheme is really simple and works: the
kern_mount keeps the module use-count non-zero so long as any file
descriptors are using the module's filesystem. fput() decrements the
use-count at a safe time -- no race conditions.
The expected behaviour is as it has always been: rmmod fails if anyone
is using the module, and succeeds if nobody is using the module. The
garbage collection of modules is done using "rmmod -a" periodically, as
it always has been.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:18 EST