Just one issue. Giving up an interface just needs a readlock, not a writelock.
At some level I'm just passing along the driver model constraints ... as from device_release_driver(), which does modify sysfs data structures. Getting a readlock would mean that things like "/bin/ls" would have data structures changing underneath them.
Could you elaborate a bit? I don't think I noticed any code getting readlocks on the bus rwsem on such paths.
Isn't giving up an interface still _changing_ a binding? Usually readlocks imply read-only data.
It is in the comments.
Where?
Strictly speaking giving up a claim on an interface can race only with probing or driver unload. There's nothing wrong with two drivers doing usb_driver_release_interface() concurrently. They own the interfaces.
The locks protect data structures, and proper data structure locking is what prevents races. Like with "/bin/ls".
As probe() and unloading will take writelocks, taking a readlock here is enough. It doesn't matter in practice, but still I cannot help noticing that in a very strict sense a comment could be objected to. ;-)
I'm not sure which one though. If you're talking about the ones relating to the usb_driver_{claim,release}_device() code, you should go look at how that'll be working when we get rid of the interface.driver field ... writelocks will absolutely be required, since all those bindings will show up in sysfs.
They're required already whenever someone uses release() to get rid of a binding that was established with probe()...
- Dave
Regards Oliver
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
