Re: [RFC as402] Delaying module memory release

From: Rusty Russell (rusty_at_rustcorp.com.au)
Date: 10/27/04

  • Next message: Marcos D. Marado Torres: "Re: The naming wars continue..." 
    To: Alan Stern <stern@rowland.harvard.edu>
Date:	Wed, 27 Oct 2004 12:40:11 +1000

    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. 

    -- 
-
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/
  • Next message: Marcos D. Marado Torres: "Re: The naming wars continue..."

    Relevant Pages