(8): Reading port status messages and marking the child device
as USB_STATE_NOTATTACHED when a connect change occurs
And issuing disconnect() notifications ... that's three separate things, and I think only the third one (notifications) should require holding the device/port's lock.
Have a look at the "OHCI resume/reset stops deadlocking in PM code" patch I sent, and see how mark_children_gone() is used as part of forcibly quiescing the device (in a context where khubd can't help) ... there should be a safely spinlocked version of that, used also inside khubd, along with a variant that just changes state for any device that's actually attached ... we've discussed that before.
Unfortunately, the scheme relies on children[n]->serialize to provide mutual exclusion for (6) and (7), so (8) has to acquire that same semaphore. This means that (8) can't take place simultaneously with (1)-(5) on the child, since they will also hold the semaphore.
Or (referencing my secret decoder ring!) basically: if khubd grabs each port's lock before checking port status change events, it'll be delayed by usbfs and/or sysfs operations that need it too.
Actually khubd is pretty stupid ... when it gets a notification that one port changed, should just check that port. That'll reduce the opportunities other tasks have to cause problems for khubd.
(Hmm, the latest usbfs code grabs dev->serialize for synchronous I/O ... which means that khubd could potentially be locked out for a LONG time if it's grabbing needless locks, like today.)
There's also khubd to consider. Shouldn't it also use the same policy?
What do you mean? When and why should khubd use locktree?
To get the lock on the hub it's looking at. If that policy is ever going to be used, it should be used everywhere; else the inconsistency will create problems.
Now maybe I've overlooked something here or oversimplified in some way. But altogether I think this makes a good case that using a single lock is
the way to go.
That is, one per device, not changing away from dev->serialize?
Yes, that's what I mean.
How were you going to solve the register_driver() -> probe() path?
I'd be fine with that. We may need to address some corner cases, but the analysis I snipped suggests there shouldn't be any.
Good. So apart from the questions above, it looks like we've found a solution.
Other than removing khubd_sem, sounds like what's in my BK tree now.
- 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
