Clearly some sort of locking protection is needed. The question is, what sort? The simplest approach is to add a semaphore or spinlock protecting the children[] arrays. But given that the exceptional accesses all occur in situations that involve disconnecting all the devices on a bus, perhaps there's a more clever way to do it (although I can't think of one offhand).
How about a lock tree?
Each interior node (hub) has a lock (dev->serialize?) and they're acquired from root to leaf. Once you have a node's lock, you can release the parent lock ... to allow more parallelism. When you're done updating the children (adding, naming, removing, etc) just release that node's lock. (Or for a more advanced version: node can have rwlocks not mutexes.)
Furthermore, there are problems the simple approach doesn't solve. For example, consider what happens when rmmod of an HCD is recursively removing all the devices belong the root hub and is working its way through the children[] array of some intermediate hub, removing the entries one by one. Suppose at the same time khubd detects a new device plugged into that hub and so _fills in_ a blank children[] entry. Not a good scenario.
To add remove a node (hub or device), you must hold its parent's lock. (And not hold the usb subsystem rwsem; the driver model core grabs that to update sysfs and bind/unbind drivers.)
So whatever is removing the root hub would grab some bus-level lock and not let go. And khubd would walk down the tree from that same root, but keep only the lock for the hub with the device it's adding. One would grab that root lock first, and proceed; the other would wait till that lock was released.
That way you can do things like adding devices on one hub while removing them from another one -- concurrently.
- dave
------------------------------------------------------- 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
