I'm about ready to give up on device reset during probe.
Preventing it would need a per-interface state flag, FWIW; easily set by usbcore during probe(). Somewhat parallel to the flag I suggested be held during SET_CONFIGURATION...
Preventing it could be as simple as not writing drivers that do it. No extra flags needed. :-)
I do like the idea of friendlier failures than deadlocks inside the driver core ... deadlock on dev->serialize at least is closer to the real bug (in the usb device driver) than deadlock on the bus rwsem. Even nicer would be just a nice error code, maybe -EDEADLK.
Sysfs is just part of the problem. The whole core has to work together.
And I can't help thinking that locktree is overkill for almost all cases. Can you name any problems that it solves?
Maybe lock_port() would be a better name, actually.
Consider some cases where subtree B is a descendent of A. It'd prevent suspending B while resume notifications were still being issued somewhere in A ... including potentially part of B. (In fact there should be ~10 msec delays between suspend and resume actions ... a per-tree timer.) Likewise, suspending B while disconnect processing was being done on A, or even while the A hub was being reset.
Right now it's only used in the suspend/resume logic, but such issues aren't going to stay uncommon as more tasks start to manipulate usb tree state from userspace. And the hub code has pretty much been ignoring a lot of those issues, getting away with it because the only tree operation Linux has supported so far has been disconnect (which has been annoyingly error prone...) and most disconnects are on degenerate trees (just one device).
3. Newly registered driver is matched to all unbound USB interfaces. Neither the device nor its parent hub is locked.
But that probably doesn't actually _need_ much locking, beyond what the bus rwsem already provides. So the only issue there is that it's different.
That's a big enough issue, IMO. Have you figured out how to prevent suspend during probe if the device isn't locked? Retry the suspend in a polling loop until a flag indicates the device isn't being probed any more? How will you prevent probe of a currently-being-suspended device?
Actually, suspend during probe needs to be supported. It's an OTG protocol. Connect A-Host and B-Peripheral together; that's normal USB. The A-Host notices that the B-Peripheral isn't a supported one (not in the "Targeted Peripheral List") ... the natural way to do that is to have a driver matching all devices, and checking them against that list during probe().
Since A can't be the host with B, the problem MAY be just that B needs to be the master ... so the natural response is to have that probe() routine invoke the "Host Negotiation Protocol" (HNP) and switch roles, to A-Peripheral and B-Host. That involves setting the USB_DEVICE_B_HNP_ENABLE feature in B-Peripheral, then suspending (to initiate HNP). During probe()...
And now consider this: Every path calling probe() definitely has acquired the USB subsystem rwsem. Proper locking order requires that _no_ device locks are acquired while holding the rwsem!
... unless the calls from usbcore/hub don't hold such locks before calling the probe().
I don't understand. ...
That is, "unless the locking order is changed, which we could do, and would do in one of the hypothetical cases I'd sketched".
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
