Re: [PATCH RFD] alternative kobject release wait mechanism

["Dmitry Torokhov" <dmitry.torokhov@gmail.com>]

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/