From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeff Layton <jlayton@redhat.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
jamie@shareable.org, pavel@ucw.cz, viro@ZenIV.linux.org.uk,
duaneg@dghda.com, Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: [PATCH 2/2] vfs: force reval on dentry of bind mounted files on FS_REVAL_DOT filesystems
Date: Thu, 03 Dec 2009 10:35:21 -0800 [thread overview]
Message-ID: <m1ws13j47q.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20091203102021.0b04a6eb@barsoom.rdu.redhat.com> (Jeff Layton's message of "Thu\, 3 Dec 2009 10\:20\:21 -0500")
Jeff Layton <jlayton@redhat.com> writes:
> On Thu, 03 Dec 2009 11:58:43 +0100
> Miklos Szeredi <miklos@szeredi.hu> wrote:
>
>> On Wed, 2 Dec 2009, Jeff Layton wrote:
>> > In the case of a bind mounted file, the path walking code will assume
>> > that the cached dentry that was bind mounted is valid. This is a problem
>> > problem for NFSv4 in a way that's similar to LAST_BIND symlinks.
>> >
>> > Fix this by revalidating the dentry if FS_FOLLOW_DOT is set and
>> > __follow_mount returns true.
>> >
>> > Note that in the non-open codepath, we cannot return an error to the
>> > lookup if the revalidation fails. Doing so will leave a bind mount in
>> > a state such that we can't unmount it. In that case we'll just have to
>> > settle for d_invalidating it (which should mostly turn out to be a
>> > d_drop in this case) and returning success.
>>
>> The only worry I have is that this adds an extra branch in a very hot
>> codepath (do_lookup). An error can't be returned, as you note, and
>> for bind mounted directories d_invalidate() will not succeed: the
>> directory is busy, it's referenced by the mount. So basically the
>> only thing this does is working around the NFSv4 issue. But Trond has
>> a proper solution to that, and a temporary solution could be added to
>> do_filp_open() rather than burdening do_lookup() with it, no?
>>
>
> (re-adding Trond. I forgot to cc him on this latest set)
>
> Self-NAK on this patch...
>
> That's my main worry too, and sadly it doesn't seem to be unfounded.
> This patch adds a lot of extra d_revalidate calls here. I think it's
> going to be too expensive to do this.
How so? We should only see extra calls if we follow a mount point.
Currently we call d_revalidate on every path component.
> The only problem I've identified that this fixes is with file bind
> mounts and I don't get the impression they're that common. Maybe the
> best thing is to just fix the LAST_BIND symlink case for now and wait
> for Trond or Al's overhaul of this code.
Well right now following mount points breaks the VFS contract that we
will revalidate all dentries before we use them. That breaking of the
contract breaks NFS.
I don't know what else d_revalidate is good for. On the sysfs side
I only use it to unhash the dentry. Something we don't care about
from the do_lookup side of things if we have a bind mount.
I'm not clear what kind of changes revalidating a deleted but open
file will give you on NFS.
Eric
next prev parent reply other threads:[~2009-12-03 18:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-02 19:59 [PATCH 0/2] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #6) Jeff Layton
2009-12-02 19:59 ` [PATCH 1/2] vfs: force reval of target when following LAST_BIND symlinks Jeff Layton
2009-12-02 23:53 ` Eric W. Biederman
2009-12-03 10:39 ` Miklos Szeredi
2009-12-02 19:59 ` [PATCH 2/2] vfs: force reval on dentry of bind mounted files on FS_REVAL_DOT filesystems Jeff Layton
2009-12-03 0:01 ` Eric W. Biederman
2009-12-03 1:23 ` Jeff Layton
2009-12-03 10:58 ` Miklos Szeredi
2009-12-03 11:11 ` Eric W. Biederman
2009-12-03 11:19 ` Miklos Szeredi
2009-12-03 11:56 ` Eric W. Biederman
2009-12-03 15:21 ` Miklos Szeredi
2009-12-03 15:20 ` Jeff Layton
2009-12-03 18:35 ` Eric W. Biederman [this message]
2009-12-03 19:15 ` Jeff Layton
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=m1ws13j47q.fsf@fess.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=duaneg@dghda.com \
--cc=jamie@shareable.org \
--cc=jlayton@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=pavel@ucw.cz \
--cc=trond.myklebust@fys.uio.no \
--cc=viro@ZenIV.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