On Mon, 1 Aug 2005, Patrick Mochel wrote: > > I agree that a parent may have to cope with situations where two children > > are trying to change state at the same time. struct device->semaphore > > should help there. This doesn't affect what I wrote, however. Link-state > > changes don't involve races, because a link state describes the > > connection between one specific parent and one specific child. If two > > different links change state at the same time, that's not a race. > > For two children changing state at the same time, it is not a race. But, > there could be potentially racy conditions when notifying the parent. > Maybe. As I think about it more, I'm not sure it's possible to get mixed > up, since there should always be _some_ delay between a parent receiving a > notification that a child has suspended and the parent actually suspending > itself. This is why we want the driver to lock the parent before notifying it. And since the driver will already be holding the child's lock, this is a case where we need to acquire locks in the wrong order (going up the tree). > > Me neither. In fact, I would go so far as to say that this is the main > > impediment to RTPM implementations at the moment. If I knew the answer to > > the locking-order problem, I could fix up the USB RTPM code right now. > > What exactly is the impediment? The locking constraints? Yes. In a separate message you worried about what happens when there are multiple parents. I don't see that being a problem here, because for power-state notifications we will only need to lock one parent at a time: the one currently being notified. Right now I'm leaning toward a solution that explicitly allows acquiring locks in either order (up or down), with the proviso that a process trying to lock upward will lose if another process is trying to lock the same devices downward. That is, if A > B, P1 has locked A, P2 has locked B, and P2 is trying to lock A while P1 is trying to lock B, then P2's locking attempt will fail rather than block. That should be sufficient to avoid deadlock. I think this is the sort of behavior we want to see. Lock acquisition going down the tree tends to be for more important reasons, like unbinding drivers and unregistering devices. Lock acquisition going up tends to be for less important things (like RTPM) which will usually be made irrelevant by the downward-going process anyhow. After all, there's no point having a thread trying to change a power state block another thread that wants to unregister the device! Now I just need to come up with a clean way to implement it... Alan Stern
