Re: Rusty's module talk at the Kernel Summit

[Daniel Phillips <phillips@arcor.de>]

On Thursday 11 July 2002 09:14, Rusty Russell wrote:
> In message you write:
> > Not needed.  Really not needed (just wait for a couple of days until
> > I get the infrastructure for race-free register/unregister on generic
> > stuff into submittable shape).
> 
> Yes, I look forward to your code.
> 
> There's no point discussing this until we see your solution, is there?

Except to say that this exactly mirrors my conclusion - after looking at all 
the finicky, nasty ways there are of trying to count users of modules at the 
call level I went back and looked at the filesystem interface, which is 
already very nearly race free.  It works by dumping the job of counting 
subsystem users on the subsystem interface, instead of trying to make the 
module interface do it.

In this case, counting users ends up being mount/unmount's job, which only 
needs a simple interaction with register/unregister_filesystem to be 
completely raceless.  Then register/unregister are directly coupled to 
insmod/rmmod so that, for instance, unregister can fail because rmmod called 
it when it still had users.

Closing the rmmod race with this interface is easy.  We can for example just 
keep a state variable in the module struct (protected by a lock) to say the 
module is in the process of being deregistered.  The same state variable 
prevents races during the registration process, that is, mount will not 
succeed if the module is in the process of being registered.  The rest of the 
potential module races are in the symbol handling: the first thing insmod 
does is create the symbol in the 'registering' state; the last thing it does 
is remove it, while in the 'deregistering' state.

Note how the rmmod-during-ret race just disappeared, because rmmod directly 
calls deregister, which either succeeds or doesn't.  If it succeeds there are 
no mounts on the module and everything is quiet, remove away.  Easy huh?  
Note also how we don't really have to divide up the 'deactivate' and 
'destroy' parts of the deregistration process, though I can see why it still 
might be useful to do that.  Such refinements become a concern of the 
filesystem machinery, not the module interface.

This is all by way of saying that Al is apparently well advanced in 
implementing exactly the strategy I'd intended to demonstrate (Rusty and 
Keith seem to be heading to the same place as well, by a twistier path).  I'm 
more than happy to bow out now, because I won't be waking up any more in the 
middle of the night in a cold sweat brought on by fear of rmmod disappearing 
from my favorite OS.

-- 
Daniel