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 - 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:28 EST