Re: [Patch -mm 0/3] RFC: module unloading vs. release function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/16/07, Alan Stern <[email protected]> wrote:
On Mon, 16 Apr 2007, Dmitry Torokhov wrote:

> On 4/16/07, Cornelia Huck <[email protected]> wrote:
> > Hi,
> >
> > based on the discussion in "How should an exit routine wait for
> > release() callbacks?", I've cooked up some patches that make module
> > unload wait until the last reference for a kobject has been dropped.
> > This should plug the "release function in already deleted module" race;
> > however, if the last kobject_put() from the module containing the
> > release function is not in the module's exit function, there's still a
> > small window (not sure if and how to plug this).
>
> Unfortunately all this "wait for refcount in module's exit" schemas
> lead to the following deadlock:
>
>         rmmod my_module < /path/to/some/file/incrementing/my/refcount

(Note that this problem will be a lot harder to provoke once Tejun's
changes to sysfs are in place.  But it will still be possible, unless we
make similar changes to all the other filesystems as well.)

There are three possible approaches to this problem:

    1. Ignore it, as we do now.  If someone actually tries running your
       example above, an oops will result when the kobject's release
       method is called after my_module has been unloaded from memory.

    2. Do what Cornelia suggested, and allow the example to deadlock.

    3. Change the module code so that rmmod can return _before_ the
       module is actually unloaded from memory (but after the module's
       exit routine has completed).  This will lead to more problems.
       For example, what if someone tries to modprobe my_module back
       again before it has finished unloading?

My feeling is that either a deadlock or more complications with modprobe
would be preferable to an oops.  Your opinion may differ.


What about 4:

    When registering an [k]object increment refcount of module that
provides ->release() function.

That would normally require ->release function to be placed on
subsystem level to allow unloading individual devices.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux