Nest rename_lock inside vfsmount_lock
authorAl Viro <viro@zeniv.linux.org.uk>
Tue, 26 Mar 2013 22:25:57 +0000 (18:25 -0400)
committerBen Hutchings <ben@decadent.org.uk>
Wed, 10 Apr 2013 02:20:03 +0000 (03:20 +0100)
commita0a551fcc3199a6e9fb6c0236daff99bbe278905
tree97b3159b14cfa14400549672f7501f00340414ba
parent509d8d1dcefb35111b3f1e24f56be7d956cef439
Nest rename_lock inside vfsmount_lock

commit 7ea600b5314529f9d1b9d6d3c41cb26fce6a7a4a upstream.

... lest we get livelocks between path_is_under() and d_path() and friends.

The thing is, wrt fairness lglocks are more similar to rwsems than to rwlocks;
it is possible to have thread B spin on attempt to take lock shared while thread
A is already holding it shared, if B is on lower-numbered CPU than A and there's
a thread C spinning on attempt to take the same lock exclusive.

As the result, we need consistent ordering between vfsmount_lock (lglock) and
rename_lock (seq_lock), even though everything that takes both is going to take
vfsmount_lock only shared.

Spotted-by: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: Backported to 3.2:
 - Adjust context
 - s/&vfsmount_lock/vfsmount_lock/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
fs/dcache.c