linux-kernel - Re: [PATCH RFC] vfs: make fstatat retry 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: <20120417102035.2236e553@corrin.poochiereds.net>
Date:	Tue, 17 Apr 2012 10:20:35 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
Cc:	Miklos Szeredi <miklos@...redi.hu>,
	Bernd Schubert <bernd.schubert@...m.fraunhofer.de>,
	Malahal Naineni <malahal@...ibm.com>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pstaubach@...grid.com" <pstaubach@...grid.com>,
	"viro@...IV.linux.org.uk" <viro@...IV.linux.org.uk>,
	"hch@...radead.org" <hch@...radead.org>,
	"michael.brantley@...haw.com" <michael.brantley@...haw.com>,
	"sven.breuner@...m.fraunhofer.de" <sven.breuner@...m.fraunhofer.de>
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from
 getattr call

On Tue, 17 Apr 2012 14:04:34 +0000
"Myklebust, Trond" <Trond.Myklebust@...app.com> wrote:

> On Tue, 2012-04-17 at 09:32 -0400, Jeff Layton wrote:
> > On Tue, 17 Apr 2012 15:12:20 +0200
> > Miklos Szeredi <miklos@...redi.hu> wrote:
> 
> > To do that would require protocol support that we simply don't have. We
> > don't have a way to (for instance) say via NFS "give me the attributes
> > for this filename". Well, at least not for NFSv3...
> 
> What's wrong with LOOKUP?
> 

Some of this is due to my decision to use fstatat as an example, but we
should bear in mind that I've just been using that as an example. We'll
eventually have to do something similar for all path based syscalls in
order to fix tihs comprehensively.

While it may be possible to handle stat type calls atomically with a
simple LOOKUP call, other operations may require more than one round
trip. Consider chmod(), for instance...

> > With v4 you could theoretically construct a compound that does that,
> > but you'd have to assume that the server won't release the reference to
> > the inode midway through the compound. That's a reasonably safe
> > assumption.
> 
> Actually, NFSv4 is the one that has the problem: there are no atomicity
> guarantees within compounds, so you could theoretically get an ESTALE in
> the GETATTR part of our lookup compound.
> 

Well, it's possible, but it seems pathological to me for a server to do
that...

Bruce and I were discussing this the other day. It would be good to add
something like this to the RFCs:

"On a PUTFH, a server SHOULD hold a reference to the filehandle such
that it does not go stale over the life of the compound."

...or something along those lines. That's a different matter though and
not directly related to this. :)

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