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@xxxxxxxxx> 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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
