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: <20120423080012.7c23ef24@tlielax.poochiereds.net>
Date:	Mon, 23 Apr 2012 08:00:12 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	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, bfields@...ldses.org,
	trond.myklebust@....uio.no, rees@...ch.edu
Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors
 from getattr call

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.

Seems like it ought to be possible to eliminate that race for other
filesystems as well, by turning those into an ESTALE return and
retrying again.

> For non directories we basically have getattr and setattr.   NFSv4 can
> handle both without retries if we supply the name instead of the
> handle (i.e. i_op->getattr_by_name, i_op->setattr_by_name).  Other
> protocols can do whatever they want, exponential backoff with limited
> number of retries, whatever.
> 
> No looping required in the VFS.
> 

Per-name operations for things like getattr and setattr would be nice.
It would also make things cleaner on CIFS since there'd be less
conversion from dentry to path.

Note that we would still need to do a lookup. We have to update the
inode attributes with these operations too. But, that would likely
avoid the ESTALE problems with NFS since we could retry within
the lower fs itself.

That said, there's more than just those two operations involved. We'd
need similar ones for other inode operations too:

readlink
permission
*xattr

...and probably others, especially if you want to allow for more
resilient create/delete in the face of a stale directory.

-- 
Jeff Layton <jlayton@...hat.com>
--
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/