Revert "vfs: stop d_splice_alias creating directory aliases"
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 8 Jun 2012 17:34:03 +0000 (10:34 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Fri, 8 Jun 2012 17:34:03 +0000 (10:34 -0700)
commit32ba9c3fcab960f0b0d332c86ebcd2c4870d9bb8
treecd3638359e7a635dc15856559ac01b14196c4ff7
parent0b35d326f813a654f0cd40f513bd95e3935921c1
Revert "vfs: stop d_splice_alias creating directory aliases"

This reverts commit 7732a557b1342c6e6966efb5f07effcf99f56167 (and commit
3f50fff4dace23d3cfeb195d5cd4ee813cee68b7, which was a follow-up
cleanup).

We're chasing an elusive bug that Dave Jones can apparently reproduce
using his system call fuzzer tool, and that looks like some kind of
locking ordering problem on the directory i_mutex chain.  Our i_mutex
locking is rather complex, and depends on the topological ordering of
the directories, which is why we have been very wary of splicing
directory entries around.

Of course, we really don't want to ever see aliased unconnected
directories anyway, so none of this should ever happen, but this revert
aims to basically get us back to a known older state.

Bruce points to some of the previous discussion at

       http://marc.info/?i=<20110310105821.GE22723@ZenIV.linux.org.uk>

and in particular a long post from Neil:

       http://marc.info/?i=<20110311150749.2fa2be66@notabene.brown>

It should be noted that it's possible that Dave's problems come from
other changes altohgether, including possibly just the fact that Dave
constantly is teachning his fuzzer new tricks.  So what appears to be a
new bug could in fact be an old one that just gets newly triggered, but
reverting these patches as "still under heavy discussion" is the right
thing regardless.

Requested-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/dcache.c