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 - 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 : Mon Jul 15 2002 - 22:00:20 EST