[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120608162234.GB17251@fieldses.org>
Date: Fri, 8 Jun 2012 12:22:34 -0400
From: "J. Bruce Fields" <bfields@...ldses.org>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Dave Jones <davej@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Miklos Szeredi <mszeredi@...e.cz>, Jan Kara <jack@...e.cz>,
Peter Zijlstra <peterz@...radead.org>,
linux-fsdevel@...r.kernel.org,
"J. Bruce Fields" <bfields@...hat.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Sage Weil <sage@...dream.net>
Subject: Re: processes hung after sys_renameat, and 'missing' processes
On Thu, Jun 07, 2012 at 08:36:07PM +0100, Al Viro wrote:
> * d_splice_alias() - broken. Called without any locking on the
> old directory, nevermind ->s_vfs_rename_mutex.
I was assuming that the callers were in lookup, held i_mutex on a
parent, and that in the case of a directory, existence of an alias with
a different parent could only result from a filesystem bug.
> I really believe that this pair of commits needs to be reverted. The
> earlier code used to guarantee that alias would be detached.
In the case that prompted that first commit, the directory in question
had an alias that was detached (which I'm taking to mean IS_ROOT(dentry)
was true?), but not flagged DISCONNECTED. The particular case was only
reproduceable on an older kernel, and I couldn't find a similar
reproducer on recent upstream, but I also couldn't convince myself it
was impossible.
So, maybe the correct thing is to revert that change. Or maybe it
should be picking an IS_ROOT dentry instead of a DISCONNECTED one?
There's some previous discussion at
http://marc.info/?i=<20110310105821.GE22723@...IV.linux.org.uk>
(in particular a long post from Neil:
http://marc.info/?i=<20110311150749.2fa2be66@...abene.brown>
that I should review.)
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists