lkml.org 
[lkml]   [2007]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFD] alternative kobject release wait mechanism
    On 4/18/07, Tejun Heo <htejun@gmail.com> wrote:
    > Hello,
    >
    > Alan Stern wrote:
    > > On Wed, 18 Apr 2007, Tejun Heo wrote:
    > >
    > >> Hello, all.
    > >>
    > >> Agreed with the problem but I'm not very enthusiastic for adding
    > >> kobj->owner. How about the following? exit() routines will have to
    > >> do device_unregister_wait() instead of device_unregister(). On return
    > >> from it, it's guaranteed that all references to it are dropped and
    > >> ->release is finished. The caller is responsible for avoiding
    > >> deadlock, of course.
    > >
    > > There's a problem with this approach.
    > >
    > > Many drivers, especially those for hot-pluggable buses, register and
    > > unregister devices dynamically. These events can occur in time-critical
    > > situations, where the driver cannot afford to wait for all the references
    > > to be dropped when unregistering a device. It's okay to wait in a module
    > > exit routine, but to make things work the routine would have to wait for
    > > references to _all_ unregistered objects to go away, not just the
    > > references for the objects it unregisters at exit time.
    > >
    > > So let's see what changes are needed to make the approach workable. We
    > > will have to maintain a count of objects whose release methods haven't
    > > been called yet. The count has to be incremented every time an object is
    > > unregistered (or registered, it doesn't matter which) and decremented
    > > _after_ the release method returns -- meaning somewhere in the driver
    > > core. When the count goes to zero, the exit routine is then allowed to
    > > terminate.
    > >
    > > Hmmm, this is beginning to sound like a module-wide refcount which serves
    > > to block mod->exit(). In fact, it sounds almost identical to what
    > > Cornelia wrote, except that the refcount refers only to devices rather
    > > than arbitrary kobjects (and except that the blockage just before
    > > mod->exit returns instead of just after). You can see where I'm
    > > leading...
    >
    > The goal of immediate-disconnect is to remove such lingering reference
    > counts so that device_unregister() or driver detach puts the last
    > reference count.
    >
    > You tell a higher layer that a device is going away, on return from the
    > function, that layer isn't gonna access the device anymore. ie. On
    > return from the unregistration function, the upper layer shouldn't have
    > any reference to the device. If you unregister from all layers a device
    > is registered to, you are left with only 1 reference which you put with
    > device_unregister(). After all are converted, reference count doesn't
    > mean much. struct device isn't a reference counted object anymore.
    >
    > I don't think this is gonna be too difficult to do. I think I can
    > convert block layer and IDE/SCSI drivers without too much problem.
    > Dunno much about other layers tho.

    I am still do not understand why this is needed. Would it not be
    simplier just to use a reference to struct device instead of embedding
    it in a larger structure if their lifetimes are different and one does
    not have a subsystem that takes care of releasing logic.


    Pretty much drivers have 2 options:

    struct my_device {
    void *private_data;
    struct device dev;
    };

    In this case ->release must live in a subsystem code; individual
    drivers kfree(my_dev->private) and do any additional cleanup after
    calling device_unregister(&my_dev->dev);

    Second option:

    struct my_device {
    type member1;
    type member2;

    struct device *dev;
    };

    dev is coming from _device_create(). Driver core takes care of
    releasing dev structure; driver does cleanup of my_device.

    With current sysfs orphaning attributes upon removal request there is
    no issue of accessing driver-private data through references obtained
    via ether embedded or referenced dev structure so everything is fine.

    --
    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/

    \
     
     \ /
      Last update: 2007-04-18 18:45    [W:0.027 / U:0.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site