Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: [RFC] Raceless module interface | Date | Thu, 12 Sep 2002 05:32:31 +0200 |
| |
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/
|  |