linux-kernel - Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120423133412.GB13681@fieldses.org>
Date:	Mon, 23 Apr 2012 09:34:12 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	Malahal Naineni <malahal@...ibm.com>,
	Steve Dickson <SteveD@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org, michael.brantley@...haw.com,
	sven.breuner@...m.fraunhofer.de, chuck.lever@...cle.com,
	pstaubach@...grid.com, trond.myklebust@....uio.no, rees@...ch.edu
Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors
 from getattr call

On Mon, Apr 23, 2012 at 09:12:55AM -0400, Jeff Layton wrote:
> On Mon, 23 Apr 2012 09:00:09 -0400
> "J. Bruce Fields" <bfields@...ldses.org> wrote:
> 
> > On Mon, Apr 23, 2012 at 08:00:12AM -0400, Jeff Layton wrote:
> > > On Sun, 22 Apr 2012 07:40:57 +0200
> > > Miklos Szeredi <miklos@...redi.hu> wrote:
> > > 
> > > > On Fri, Apr 20, 2012 at 11:13 PM, Jeff Layton <jlayton@...hat.com> wrote:
> > > > > On Fri, 20 Apr 2012 15:37:26 -0500
> > > > > Malahal Naineni <malahal@...ibm.com> wrote:
> > > > >
> > > > >> Steve Dickson [SteveD@...hat.com] wrote:
> > > > >> > > 2) if we assume that it is fairly representative of one, how can we
> > > > >> > > achieve retrying indefinitely with NFS, or at least some large finite
> > > > >> > > amount?
> > > > >> > The amount of looping would be peer speculation. If the problem can
> > > > >> > not be handled by one simple retry I would say we simply pass the
> > > > >> > error up to the app... Its an application issue...
> > > > >>
> > > > >> As someone said, ESTALE is an incorrect errno for a path based call.
> > > > >> How about turning ESTALE into ENOENT after a retry or few retries?
> > > > >>
> > > > >
> > > > > It's not really the same thing. One could envision an application
> > > > > that's repeatedly renaming a new file on top of another one. The file
> > > > > is never missing from the namespace of the server, but you could still
> > > > > end up getting an ESTALE.
> > > > >
> > > > > That would break other atomicity guarantees in an even worse way, IMO...
> > > > 
> > > > For directory operations ESTALE *is* equivalent to ENOENT if already
> > > > retrying with LOOKUP_REVAL.  Think about it.  Atomic replacement by
> > > > another directory with rename(2) is not an excuse here actually.
> > > > Local filesystems too can end up with IS_DEAD directory after lookup
> > > > in that case.
> > > > 
> > > 
> > > Doesn't that violate POSIX? rename(2) is supposed to be atomic, and I
> > > can't see where there's any exception for that for directories.
> > 
> > Hm, but that only allows atomic replacement of the last component of a
> > path.
> > 
> > Suppose you're looking up a path, you've so far reached intermediate
> > directory "D", and the next step of the lookup (of some entry in D)
> > returns ESTALE.  Then either:
> > 
> > 	- D has since been unlinked, and ENOENT is obviously right.
> > 	- D was unlinked and then replaced by something else, in which
> > 	  case there was still a moment when ENOENT was correct.
> > 	- D was replaced atomically by a rename.  But for the rename to
> > 	  work it must have been replacing an empty directory, so there
> > 	  was still a moment when ENOENT would have been correct.
> 
> I don't think so...D should always exist in the namespace, so ENOENT
> would not be correct.

The operation above is a lookup in D, not a lookup of D.

> Just because it was empty doesn't mean that it
> didn't exist...
> 
> > 	  (Exception: if D was actually a regular file or some other
> > 	  non-directory object, then ENOTDIR would be the right error:
> > 	  but if you're able to get at least object type atomically with
> > 	  a lookup, then you should have noticed this already on lookup
> > 	  of D.)
> > 
> > I think that's what Miklos meant?
> > 
> > --b.
> 
> Here's an example -- suppose we have two directories: /foo
> and /bar. /bar is empty. We call:
> 
>     rename("/foo","/bar");
> 
> ...and at the same time, someone is calling:
> 
>     stat("/bar");
> 
> ...the calls race and in this condition the stat() gets ESTALE back
> -- /bar got replaced after we did the lookup.
> 
> According to POSIX, the name "/bar" should never be absent from the
> namespace in this situation, so I'm not sure I understand why returning
> ENOENT here would be acceptable.

Yes, agreed, my assertion was just that an ESTALE on a lookup of a
non-final component is probably equivalent to ENOENT.

I'm not sure if that's what Miklos meant.

--b.
--
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/