On Wed, 1 Jun 2005, Dmitry Torokhov wrote:
> > > 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.
Agreed this is unlikely. What you're doing right now (check that the
currently bound driver is yours) should solve the problem. Of course the
check must be done while CPU1 holds the semaphore.
Alan Stern
-------------------------------------------------------
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
