]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit479a4352643f5e640b9f8b0b9bc2cf133479cda2
treecd3638359e7a635dc15856559ac01b14196c4ff7
parent952223f89af69151554207da709b2dbc6cfb9fb3
Revert "vfs: stop d_splice_alias creating directory aliases"

This reverts commit 337b6cb96e1d6ef4548c0fb1d1c01e30010cca59 (and commit
412a692d9feabbb5eec1dc732b1cd77a8935690e, 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