lkml.org 
[lkml]   [2002]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Question about pseudo filesystems
    Date
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:28    [W:2.433 / U:2.516 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site