On Tue, 1 Sep 2009, Jan Blunck wrote: > On Tue, Sep 01, Alan Stern wrote: > > > On Tue, 1 Sep 2009, Jan Blunck wrote: > > > > > > This is semaphore->mutex conversion madness from tglx. What he tried > > > > to do just doesn't work with lockdep. > > > > > > > > > > If this is a parent->child relationship and the parent is always locked before > > > the child this works perfectly with lockdep. The inode->i_mutex is doing > > > it. How is the lock in your code different from that? > > > > Maybe you're right and it's not different. I'm not so sure. What > > about parent-child-grandchild relationships? What about situations > > where multiple siblings are locked concurrently after first acquiring > > the parent's lock to make it safe (not that I'm aware of any such > > things occurring in the kernel, but they might)? > > You have to come up with a locking order on the siblings to make it deadlock > free. After that you teach the locking order to lockdep and everything should > be fine. That's not true at all. Provided you always lock the parent before locking any of the children, the order in which you lock the children doesn't matter; it cannot deadlock. > If nobody is working on this I'll try to come up with a few patches tomorrow. Okay. Peter Zijlstra had some thoughts when this issue came up a week or two ago, CC'ing him. Do you have to specify at the time you lock a mutex whether it is a parent or a child? What happens if it is both? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
