Messages in this thread | | | Date | Fri, 12 Nov 2010 10:44:24 -0800 | From | Dmitry Torokhov <> | Subject | Re: [PATCH 8/19]: SCST SYSFS interface implementation |
| |
On Fri, Nov 12, 2010 at 01:09:48PM +0100, Bart Van Assche wrote: > On Fri, Nov 12, 2010 at 2:23 AM, Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > On Thu, Nov 11, 2010 at 11:50:01PM +0300, Vladislav Bolkhovitin wrote: > > > [ ... ] > > > > > > This is the last internal put. All other references are from outsiders. > > > So, we are waiting for all them to put before we go on. > > > > The question is why do you need to wait here? I presume it is module > > unloading path, but then it is quite bad - you can easily wedge your > > subsystem if you make something to take a reference to your kobject > > while module is trying to be unloaded. Back when sysfs attributes tied > > kobjects the easiest thing was to do: > > > > rmmod <module> < / sys/devices/..../attribute > > > > If you are done with the kobject - just proceed with what you were doing > > and let it die its own peaceful death some time later. You just need to > > make sure release code sticks around to free it and your subsystem core > > can be tasked with this. Use module counter to prevent unloading of the > > subsystem core until all kobjects belonging to the subsystem are > > destroyed. > > Do you mean keeping a kref object in the kernel module, invoking > kref_get() every time a kobject has been created and invoking > kref_put() from the kobject/ktype release method ? That would help to > reduce the race window but would not eliminate all races: as soon as > the last kref_put() has been invoked from the release method, the > module can get unloaded. And module unloading involves freeing all > module code sections, including the section that contains the > implementation of the release method. Which is a race condition.
No, you do not add a kref, but rather manipulate module use counter:
static void blah_blah_release(struct kobject *kobj) { struct blah_blah *b = to_blah_blah(kobj);
... kfree(kobj);
module_put(THIS_MODULE); }
int blah_blah_register(struct blah_blah *blah) { ...
__module_get(THIS_MODULE);
...
return 0; }
The above should reside in subsystem _core_ and it will pin the core module until last kobject belonging to the subsystem is released. Once all users are gone module counter will go to 0 and rmmod will allow core to unload. Note that no new kobjects will be created while module usage count is 0 because there are no users of the core - all of them have to be unloaded already, otherwise module loader would have bumped up usage count as well.
> > I'm not sure that it is even possible with the current kobject > implementation to solve this race.
It is possible and it is solved in most (all?) mainline subsystems.
> I haven't found any information > about this race in Documentation/kobject.txt. And it seems to me that > the code in samples/kobject/kobject-example.c is vulnerable to this > race: methods like foo_show() and foo_store() can access statically > allocated memory ("static int foo") after the module has been > unloaded. Although the race window is small, this makes me wonder > whether module unloading been overlooked at the time the kobject > subsystem has been designed and implemented ? > > Bart.
-- 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/
| |