On Mon, 20 Oct 2003, David Brownell wrote:
Actually if you look around, you'll notice usbcore uses about four different locks (including dev->serialize) to protect critical sections against changes to device binding ... but the only lock that's _correct_ to use is usb_bus_type.subsys.rwsem though!
(Though there's at least one place that also needs to use dev->serialize to also protect against _config changes_ too.)
As I see it, we've got a bunch of things that need locking protection, including:
1. connect and disconnect events (device creation and deletion and also address-0 handling);
The address-0 lock is internal to the hub driver and is only needed between the time a port reset starts and the time the set_address() completes. It shouldn't affect anything else, except maybe hooking the device into the hub tree.
Creation/deleting the interface devices is part of changing device configuration. It's protected by dev->serialize. When the driver core tries to bind drivers to those new devices, then (2) applies:
2. driver probe() and disconnect() calls, also binding and unbinding events;
The probe()/disconnect() is locked by the driver model core, using usb_bus_type.subsys.rwsem, when it adds/removes devices.
That completely removes the need for driver->serialize, which is only acquired when that writelock is already held!
But the explicit usb_driver_{claim,release}_interface() calls
don't yet interact with the driver model core. They're broken;
that's why sysfs doesn't show when usbfs claims interfaces,
among other things.3. configuration and related device state changes.
See #1 above ...
Is it now generally accepted that usb_bus_type.subsys.rwsem is the correct lock for 1 and 2? Likewise, is it accepted that dev->serialize is the correct lock for 3?
See above. I certainly wrote the config change code to rely on dev->serialize being the top lock in a two-layer scheme. (Lower lock being controlled by driver model core.)
The reason I was looking at this is because of the claim/release stuff. There's a correct way to do this in the driver model, but using it means sorting out some of that mess. Given the state of 2.6 (slush, if not freeze) I'm hunting for minimal fixes.
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
