>>> Seems reasonable to me. You might also want to mention that elsewhere >>> the sequence is unlock cgroup_mutex followed by inode->i_mutex. >>> >>> Acked-by: Balbir Singh balbir@xxxxxxxxxxxxxxxxxx >> >> No, the unlock order is irrelevant. It's the lock order that matters. So >> this patch >> fixes nothing. >> >> Xiaotian, you didn't run into deadlock, did you? >> > > > Li, Consider the following > > > lock(A) > lock(B) > unlock(A) > unlock(B) > > Tomorrow if a unsuspecting programmer does this > > lock(A) > lock(B) > unlock(A) > > code block > > unlock(B) > > > What protects code block? lock B? Is that the intention? > I won't worry about that. If unlock order is a concern, we should have taught lockdep to detect it. Here's a reply from Linus on this issue: http://lkml.org/lkml/2008/10/8/150 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
