On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
>
> > On 6/1/05, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > 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
> > > case there would have to be a single driver-wide semaphore protecting
> > > intf->dev.driver_data for all interfaces controlled by the driver. And
> > > even that could theoretically fail if more than one driver was capable of
> > > binding to the interface.
> >
> > Right. In serio/gameport code we take a lock and then check if
> > currently bound driver is still "us". This way we can detect if device
> > was switched to alternate driver. If it still the same driver we asume
> > that the data returned is still relevant even if device was
> > disconnected and reconnected. Maybe we need some kind of versioning to
> > see if attribute object is stale or not.
>
> I'm not sure what more you would need beyond checking that dev.driver_data
> != NULL. If the device was physically disconnected then there's no
> problem -- once your driver's disconnect routine runs no other driver is
> allowed to bind to the interface, so dev.driver_data will certainly be
> NULL. Conversely, if the device remained physically connected but your
> driver was unbound and then rebound, the dev.driver_data value would refer
> to the current instance of your private data. There won't be any pointers
> to stale data.
>
> The only possibility for confusion is when the attribute still exists but
> the private data doesn't. Using a private semaphore for synchronization,
> you can guarantee that dev.driver_data is NULL whenever your driver is
> bound to the interface and the private data doesn't exist. (Although it
> might be a good idea for usbcore to call usb_set_intfdata(intf, NULL)
> whenever a probe fails...)
>
Well, it is just an extreme scenario:
CPU1: enters acecad attribute code and waits on semaphore
CPU2: driver unbings from interface
another driver binds to interface
dev.driver_data now points to the new private structure
("struct blah" instead of "struct acecead")
CPU1: finally woken up
CPU1 uses struct blah without noticing anything wrong.
Again, this is very unlikely, but as far as I understand we can not
rely on semaphore being available to CPU1 before servive 2nd request
from CPU2.
--
Dmitry
-------------------------------------------------------
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
