From: Al Viro <viro@ZenIV.linux.org.uk>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ReiserFS Mailing List <reiserfs-devel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@ftp.linux.org.uk>,
Alexander Beregalov <a.beregalov@gmail.com>,
David <david@unsolicited.net>
Subject: Re: [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len
Date: Sun, 3 May 2009 09:52:36 +0100 [thread overview]
Message-ID: <20090503085236.GT8633@ZenIV.linux.org.uk> (raw)
In-Reply-To: <49FB1F20.8040400@suse.com>
On Fri, May 01, 2009 at 12:11:12PM -0400, Jeff Mahoney wrote:
> 2.6.30-rc3 introduced some sanity checks in the VFS code to avoid NFS
> bugs by ensuring that lookup_one_len is always called under i_mutex.
>
> This patch expands the i_mutex locking to enclose lookup_one_len. This was
> always required, but not not enforced in the reiserfs code since it
> does locking around the xattr interactions with the xattr_sem.
>
> This is obvious enough, but it survived an overnight 50 thread ACL test.
It's not enough, unfortunately ;-/ It deals with the warning, but it
leaves an actual hole in there.
Look: what happens if we mount it r/o without that directory and then
remount r/w? We get dentry for privroot, hash it (negative at that point),
then do actual mkdir, unlock root and modify the ->d_compare() of root
to reject lookups on that sucker. Too late - in the meanwhile lookups
might very well come and find privroot in dcache.
BTW, the way ->d_compare() is done in there is rather dumb -
if (q1 == &priv_root->d_name)
return -ENOENT;
...
would do just as well. Why don't we do that lookup *once* (on ->get_sb(),
before anything can come and race with us), and then just keep negative
dentry if the directory hadn't been around? And set d_compare() for root
immediately after that lookup...
I've applied your patch as-is, and unless you have objections to the
variant above I'll do that as incremental. Comments?
next prev parent reply other threads:[~2009-05-03 8:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 16:11 [PATCH] reiserfs: Expand i_mutex to enclose lookup_one_len Jeff Mahoney
2009-05-01 16:37 ` Alexander Beregalov
2009-05-01 19:56 ` Andrew Morton
2009-05-01 20:36 ` Jeff Mahoney
2009-05-03 8:52 ` Al Viro [this message]
2009-05-03 9:15 ` Al Viro
2009-05-03 10:06 ` Al Viro
2009-05-04 4:51 ` Jeff Mahoney
2009-05-04 6:13 ` Al Viro
2009-05-04 16:40 ` Jeff Mahoney
2009-05-05 19:29 ` Jeff Mahoney
2009-05-04 5:01 ` Jeff Mahoney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090503085236.GT8633@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=a.beregalov@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@unsolicited.net \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox