> > > On the other hand, remove methods typically do call dev_set_drvdata(dev,
> > > NULL). Thus a read-during-disconnect might very well end up with acecad
> > > == NULL, and so the check above is necessary.
> > >
> >
> > OK, consider this:
> >
> > CPU1: CPU2
> >
> > if (acecad == NULL) // fails
> > usb_set_intfdata(intf, NULL);
> > ...
> > kfree(acecad);
> >
> > sprintf(... acecad->blah) -> oops
> >
> > Unprotected check does not help and might as well be removed, with
> > proper locking in place it is not needed either.
>
> You are right and I was wrong.
>
> It's not so easy to synchronize operations on an attribute with driver
> operations if the driver doesn't own the attribute's kobject. In this
Are you suggesting that kobjects should have slaves whose refcounts
they control?
Regards
Oliver
-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
