[lkml]   [2010]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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
    > <> 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);



    int blah_blah_register(struct blah_blah *blah)



    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.

    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: 2010-11-12 19:47    [W:0.025 / U:33.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site