Re: [RFC] Raceless module interface

[Daniel Phillips <phillips@arcor.de>]

On Thursday 12 September 2002 04:09, Jamie Lokier wrote:
>    1. Just before a module's cleanup_module() function is called, mark
>       the module as "unloading".  This should force
>       try_inc_mod_use_count() to fail, causing its caller to behave like
>       the associated resource (e.g. filesystem) isn't actually
>       registered, and to call request_module().

My proposal produces the same effect using a slightly different
arrangement: module_cleanup() is called, and the first thing it
does is bail out with an error if there are users, or puts the
module into the inactive state (count=-1).  This forces
try_inc_mod_use_count to fail, as you say.

>    2. request_module() should simply ignore modules marked as
>       "unloading".  It should proceed to call "insmod" etc.
> 
>    3. sys_create_module() or sys_init_module() should block if there is
>       a module of the same name currently in the "unloading" state.
>       They should block until that module's cleanup_module() returns.

OK, this is a really good example of why replacing the lock_kernel
with a dedicated module_sem is good: if we do that, the right thing
happens.  Insmod will block on the module_sem until the module is
completely unloaded and removed from the list.  By the time it gets
the semaphore, everything will be in a pristine state.

The BKL on the other hand will happily relinquish control if the
cleanup sleeps, messing things up nicely.

>    4. At this point, the new instance of the module will initialise,
>       request_module() calls will return and the callers which called
>       try_inc_mod_use_count() in step 1 will continue with the resource
>       they needed.

Yes, I don't see a problem.  The problems start when you try to
shortcut this cycle.  Given that a shortcut is hardly going to save
much at all, due to caching, I'd call it a waste of effort.

-- 
Daniel