On Monday 09 September 2002 21:48, Jamie Lokier wrote:
> 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.
It wasn't obvious to you, was it. So how can you call it simple. For
modules, we need something that is truly simple, and having __exit return
a flag is it. That is not to say that Al's mechanism is wrong, at least
as far as filesystem modules go. In this case you'd rely on (part of)
it to determine the correct flag to return. It's just that this is not
the most straightforward mechanism for the job, and therefore wrong.
Besides, how much sense does it make for __exit to be incapable of
returning an error code?
> 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.
Al's analysis is all focussed on the filesystem case, where you can
prove assertions about whether the subsystem defined by the module is
active or not. This doesn't cover the whole range of module applications.
There is a significant class of module types that must rely on sheduling
techniques to prove inactivity. My suggestion covers both, Al has his
blinders on.
Designs are not always correct just because they work.
-- Daniel - 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