Alan Stern wrote:
I'm at a bit of a disadvantage here because I don't know the frequency at which this lock will be taken, nor the expected hold times.
The lock will be taken whenever:
...
Looked like a pretty good list to me. Key point: it's a lot of different code paths, which have expecteded since the earliest days of Linux-USB that they will run in parallel. Userspace code surely sees that through usbfs and sysfs; also device drivers and HCDs.
Only a few rare paths need that usbcore writelock:
- register a new driver, which rescans all devices - through usbfs, rescan all devices - unregister a driver
All other cases use the readlock mode. Reentrant locking (the rwsem "semantic" issue") is something I'll touch on in separate email.
I may have missed a few instances but that's most of them. In each case the hold time is expected to be not much more than a second (often quite a lot less). Drivers might stretch that out quite a bit if, for example, their probe() routine is slow. usb-storage can be that way, since it
Or suspend(), or resume(), or disconnect(). During most of these calls, URB completion calls trigger. Essentially any driver callback could fire ... with associated potential for misbehavior. Some of the calls will do analagous things with HCDs.
That's why I'm assuming it's not OK to switch over to a single global lock. Such a big change seems likely to bollux something up.
- Dave
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
