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]

Date:	Tue, 17 Apr 2012 18:02:13 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	Jeff Layton <jlayton@...hat.com>,
	"Myklebust\, Trond" <Trond.Myklebust@...app.com>,
	Bernd Schubert <bernd.schubert@...m.fraunhofer.de>,
	Malahal Naineni <malahal@...ibm.com>,
	"linux-nfs\@vger.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"pstaubach\@exagrid.com" <pstaubach@...grid.com>,
	"viro\@ZenIV.linux.org.uk" <viro@...IV.linux.org.uk>,
	"hch\@infradead.org" <hch@...radead.org>,
	"michael.brantley\@deshaw.com" <michael.brantley@...haw.com>,
	"sven.breuner\@itwm.fraunhofer.de" <sven.breuner@...m.fraunhofer.de>
Subject: Re: [PATCH RFC] vfs: make fstatat retry on ESTALE errors from getattr call

"J. Bruce Fields" <bfields@...ldses.org> writes:

> On Tue, Apr 17, 2012 at 10:20:35AM -0400, Jeff Layton wrote:
>> 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
>
> For "filehandle" I'd specify "current and saved filehandle".
>
>> that it does not go stale over the life of the compound."
>
> And that's *much* less of a burden on the server than requiring that the
> compound execute atomically.
>
>> ...or something along those lines. That's a different matter though and
>> not directly related to this. :)
>
> Yes.

It's only related, because it proves that it's theoretically possible to
deal with this problem without introducing infinite retries.  And that
applies to all operations, not just getattr.

As for atomicity, the VFS doesn't have any atomicity guarantees here
either.  So for example getattr("foo") may end up with st_nlink == 0
with a concurrent rename("bar", "foo").  Whether this is permitted by
the standards is another matter, but it's not something that appears to
bother anybody.

Thanks,
Miklos
--
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/