[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxxS3+NmZacr76qNmEu9=-=aw61gW1Ebugg8hdMNgKiJA@mail.gmail.com>
Date: Thu, 7 Jun 2012 16:57:13 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, Dave Jones <davej@...hat.com>,
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>,
Sage Weil <sage@...dream.net>
Subject: Re: processes hung after sys_renameat, and 'missing' processes
On Thu, Jun 7, 2012 at 4:12 PM, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> We take the approprate dentry locks in the approparite order so d_move
> and the dcache should not care in the slightest about the inode
> mutecies.
Part of the problem is that you can't even *determine* the appropriate
order without holding the rename mutex.
Now, it may turn out to be a non-issue for sysfs just because there
are no unconstrained directory renames there, but seriously: even the
d_ancestor() check itself (which is how we determine the dentry lock
order) needs that filesystem to be quiescent wrt directory renames in
order to work.
So it may not actually depend on the inode->i_mutex, but it does need
some serialization outside the dcache subsystem.
Any per-filesystem mutex should do, so if sysfs always holds the
sysfs_mutex - and never allows user-initiated renames - it should be
safe.
Linus
--
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