[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, Jul 03, 2002 at 10:25:34PM -0400, Brian Gerst wrote:
    > Leaders
    > PrivateKeith Owens wrote:
    > >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.
    > >
    > ><handwaving>
    > > Outside the module, do whatever it takes to ensure that nothing is
    > > executing any module code, including threads, command callbacks etc.
    > ></handwaving>
    > >
    > >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.
    > Why not treat a module just like any other structure? Obtain a
    > reference to it _before_ using it. I propose this change:

    Because in general you don't know you're going to use a module before
    you use it. Using a module is (necessarily) not a narrow well-defined

    David Gibson | For every complex problem there is a | solution which is simple, neat and
    | wrong. -- H.L. Mencken
    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.028 / U:13.388 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site