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    [from the cache]
©2003-2011 Jasper Spaans