On Tue, 13 Apr 2004, David Brownell wrote: > And maybe I'll have a chance to look at the patch, not just > that one issue you raised? :)
Please do! The more eyes, the better. (And don't forget the other issues I raised.) > Alan Stern wrote: > > Isn't that one of the major functions of the bus rwsem? > > Yes and no. It's used to protect data structures ... for very > brief moments, and individual driver probe() calls; so "no". > > But "yes", if you hold it a long time, it could serve as such > a lock ... but usbcore doesn't use it that way (today). > > Possibly of interest: bus_for_each_dev() uses the bus rwsem as > a topology readlock. But I don't think that's normally used > for "long" operations. AFAICT that's right, it's not used for "long" operations. But it _is_ used as a brief topology lock in bus_add_device() and bus_remove_device(). After all, _something_ has to protect the bus's device list. > It's a bit squishy. Today, that's all it really accomplishes; > the device create protection is pretty much invisible, even > inside usbcore. Drivers see it as I said. > > You're right that it _could_ be used more broadly, though. > > It's oddly like observing that while we have an army to protect our > borders, it could easily be (ab)used in wars of aggression ... ;) [I suspect it's best to keep politics out of the USB-development list :-)] Given that usbcore mainly relies on the ->serialize locks, we should stick with them and leave the bus rwsem to protect binding events. > Top down lock chaining might help ... what happens if there's a > requirement that the caller of that routine holds usbdev->serialize? > (That'd replace that little patch I sent before.) Yes, sounds good. > Clearly that "if (usbdev->children[chix])" branch, and usb_device_read(), > would need to wrap their calls with code to grab and release that lock. > > But that'd solve problems like "how do N users cat /proc/bus/usb/devices > at the same time without total serialization". (Except for that rude > "usb_bus_list_lock" ... which could become an rwsem.) It ought to -- after all, how often do USB buses get added or removed? > However, it'd probably force a few issues in khubd (as you comment). I think that's the best approach. It would solve other problems as well, like "what happens if two different threads simultaneously try to execute usb_disconnect() on overlapping parts of the device tree?" (Yes, that can't happen at the moment, but it might be a possibility in the future.) Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
