Messages in this thread | | | Date | Mon, 16 Apr 2007 15:47:13 -0400 | From | "Dmitry Torokhov" <> | Subject | Re: [Patch -mm 0/3] RFC: module unloading vs. release function |
| |
On 4/16/07, Alan Stern <stern@rowland.harvard.edu> wrote: > On Mon, 16 Apr 2007, Dmitry Torokhov wrote: > > > On 4/16/07, Cornelia Huck <cornelia.huck@de.ibm.com> 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 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/
| |