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: 14+ 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:11 ` Jeff Mahoney
2009-05-01 16:37 ` Alexander Beregalov
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.