[lkml]   [2002]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Raceless module interface
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:28    [W:0.146 / U:1.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site