linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Andreas Gruenbacher <agruen@suse.de>,
	John Johansen <jjohansen@suse.de>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: [patch 3/3] vfs: make d_path() consistent across mount operations
Date: Mon, 23 Jun 2008 15:01:44 +0100	[thread overview]
Message-ID: <20080623140144.GX28946@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20080616112830.003942737@szeredi.hu>

On Mon, Jun 16, 2008 at 01:28:07PM +0200, Miklos Szeredi wrote:
> From: Andreas Gruenbacher <agruen@suse.de>
> 
> The path that __d_path() computes can become slightly inconsistent when it
> races with mount operations: it grabs the vfsmount_lock when traversing mount
> points but immediately drops it again, only to re-grab it when it reaches the
> next mount point.  The result is that the filename computed is not always
> consisent, and the file may never have had that name. (This is unlikely, but
> still possible.)
> 
> Fix this by grabbing the vfsmount_lock for the whole duration of
> __d_path().

Umm...  I don't see problems with doing that, but I hope you realize that
the notion of "ever having that name" is not the same as "pathnam resolution
on that name ever leading to that file" - path_walk() is *NOT* atomic
wrt rename() (or mount --move, indeed) and it's quite possible to walk
into subdirectory, have it moved under you, then see .. as the next pathname
component and step out into new parent.

Said that, it makes sense to avoid dropping/regaining the lock in that
case - it's less work and I don't believe that it would increase contention
on vfsmount_lock.  So I'm applying that one, just be careful with assumptions
about consistency, etc. in the general area.

  reply	other threads:[~2008-06-23 14:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-16 11:28 [patch 0/3] vfs: d_path cleanups and fixes Miklos Szeredi
2008-06-16 11:28 ` [patch 1/3] vfs: dcache cleanups Miklos Szeredi
2008-06-16 11:28 ` [patch 2/3] vfs: fix sys_getcwd for detached mounts Miklos Szeredi
2008-06-23 13:55   ` Al Viro
2008-06-23 14:34     ` Miklos Szeredi
2008-06-23 14:41       ` Al Viro
2008-06-16 11:28 ` [patch 3/3] vfs: make d_path() consistent across mount operations Miklos Szeredi
2008-06-23 14:01   ` Al Viro [this message]
2008-06-23 14:50     ` Andreas Gruenbacher

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=20080623140144.GX28946@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=agruen@suse.de \
    --cc=hch@infradead.org \
    --cc=jjohansen@suse.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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;
as well as URLs for NNTP newsgroup(s).