Re: [RFC as402] Delaying module memory release

[Rusty Russell <rusty@rustcorp.com.au>]

On Tue, 2004-10-26 at 15:52 -0400, Alan Stern wrote:
> This issue has come up in the past, without much in the way of visible 
> results.
> 
> The problem is that sometimes the memory for a kernel module needs to be
> freed _after_ rmmod has exited.  The classic example is where the standard
> input to the rmmod process has been redirected to a pseudo-file that pins
> a kobject whose release method calls into the module.  Another example
> (which could be worked around with some effort) is multiple kernel threads
> executing in the module -- the module exit routine would have to wait for 
> each one of them to terminate.
> 
> In these cases it's not desirable/feasible to increment the module's 
> refcount.

Why not?  In the former the module is still in use, in the latter the
module_exit routine is expected to clean up.

> Instead the module's exit routine should run and rmmod should 
> return, but the module's memory should only be freed when it is known that 
> nothing else will try to use it.

[Snip poor man's two-stage module delete patch].

We've been here lots of times before.  Most people want "remove or fail"
semantics for module removal.  Two-stage delete doesn't do this, but
instead leaves modules in a "half-removed" state, where the module
cannot be used, but usually a replacement module cannot be loaded
either.  This is what "rmmod --wait" does: close off module use to
future users (ie. try_module_get() will fail) and wait for the refcnt to
hit 0.

This option has not proven popular.
Rusty.
--