OK, this patch is trivial. Just for consistency with previous unlock sequence:-)Li, Consider the followingSeems reasonable to me. You might also want to mention that elsewhereNo, the unlock order is irrelevant. It's the lock order that matters. So
the sequence is unlock cgroup_mutex followed by inode->i_mutex.
Acked-by: Balbir Singh balbir@xxxxxxxxxxxxxxxxxx
this patch
fixes nothing.
Xiaotian, you didn't run into deadlock, did you?
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