Am Sonntag, 13. Oktober 2002 18:39 schrieben Sie:
> > Races with disconnect:
> > All synchronous operations (usb_reset_device, usb_clear_halt, ...)
>
> Could you elaborate a bit?
Sure. The URBs these operations submit will not be unlinked on disconnect.
Anything that uses usb_control_msg() is vulnerable.
> > Races with probe:
> > usb_reset_device, a probe while resetting is bound to malfunction
>
> This is actually a re-enumerate operation, and should be locked
> accordingly. The only user of this today is usb-storage (as I
> recall), which needs it in some error recovery scenarios. I hope
> they don't happen during probe!
Even a storage device may have several interfaces.
And of course there's a reset ioctl through usbfs. It'd like
to remove that.
> > Would anybody object to solve this with proper locking ?
>
> What would be "proper locking"? Fixing bugs is good. :)
- add locking (down_read(&dev->serialize) to all synchronous helpers
- add down_write(&dev->serialize) to usb_reset_device()
- down_read(&dev->serialize) for probe()
- down_write(&dev->serialize) for disconnect()
- remove reset ioctl
- add lockless versions of some synchronous helpers for use in probe()
> > Would anybody object to changing the semaphore in usb_device
> > into an rw semaphore ?
>
> I've wondered about that myself. The dev->serialize semaphore
> isn't the natural model for many things, and an asymmetric lock
> would seem to be the correct model.
Good.
Regards
Oliver
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
