[lkml]   [2002]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: simple handling of module removals Re: [OKS] Module removal
    On Wed, 3 Jul 2002 05:48:09 +0200, 
    Pavel Machek <> wrote:
    >Okay. So we want modules and want them unload. And we want it bugfree.
    >So... then its okay if module unload is *slow*, right?
    >I believe you can just freeze_processes(), unload module [now its
    >safe, you *know* noone is using that module, because all processes are
    >in your refrigerator], thaw_processes().

    The devil is in the details.

    You must not freeze the process doing rmmod, that way lies deadlock.

    Modules can run their own kernel threads. When the module shuts down
    it terminates the threads but we must wait until the process entries
    for the threads have been reaped. If you are not careful, the zombie
    clean up code can refer to the module that no longer exists. You must
    not freeze any threads that belong to the module.

    You must not freeze any process that has entered the module but not yet
    incremented the use count, nor any process that has decremented the use
    count but not yet left the module. Simply looking at the EIP after
    freeze is not enough. Module code with a use count of 0 is allowed to
    call any function as long as that function does not sleep. That rule
    used to be safe, but adding preempt has turned that safe rule into a
    race, freezing processes has the same effect as preempt.

    Using freeze or any other quiesce style operation requires that the
    module clean up be split into two parts. The logic must be :-

    Check usecount == 0

    Call module unregister routine. Unlike the existing clean up code,
    this only removes externally visible interfaces, it does not delete
    module structures.

    Outside the module, do whatever it takes to ensure that nothing is
    executing any module code, including threads, command callbacks etc.

    Check the usecount again.

    If usecount is non-zero then some other code entered the module after
    checking the usecount the first time and before unregister completed.
    Either mark the module for delayed delete or reactivate the module by
    calling the module's register routine.

    If usecount is still 0 after the handwaving, then it is safe to call
    the final module clean up routine to destroy its structures, release
    hardware etc. Then (and only then) is it safe to free the module.

    Rusty and I agree that if (and it's a big if) we want to support module
    unloading safely then this is the only sane way to do it. It requires
    some moderately complex handwaving code, changes to every module (split
    init and cleanup in two) and a new version of modutils in order to do
    this method. Because of the high cost, Rusty is exploring other
    options before diving into a kernel wide change.

    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:27    [W:0.024 / U:2.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site