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: <87lillktv3.fsf@tucsk.pomaz.szeredi.hu>
Date:	Tue, 24 Apr 2012 17:54:56 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Peter Staubach <pstaubach@...grid.com>,
	Steve Dickson <SteveD@...hat.com>,
	"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-nfs\@vger.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
	"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>,
	"chuck.lever\@oracle.com" <chuck.lever@...cle.com>,
	"malahal\@us.ibm.com" <malahal@...ibm.com>,
	"bfields\@fieldses.org" <bfields@...ldses.org>,
	"trond.myklebust\@fys.uio.no" <trond.myklebust@....uio.no>,
	"rees\@umich.edu" <rees@...ch.edu>
Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call

Jeff Layton <jlayton@...hat.com> writes:

> On Mon, 23 Apr 2012 16:38:00 -0400
> Peter Staubach <pstaubach@...grid.com> wrote:
>
>> I don't really like the idea of introducing another errno as well.  It seems like too much complexity and represents complexity that no one has really justified needing.
>> 
>
> I tend to agree here. Miklos, can you elaborate a bit on what fuse
> filesystems you're particularly concerned about here? Which ones return
> ESTALE and under what conditions. Maybe we can try to tailor this
> solution to avoid the complexity without impacting them.

It is not just fuse I'm concerned about.  Grep for -ESTALE, there are
about 120 hits about 20 of which come from NFS.  There's no guarantee
that any of those ESTALE errors will go away on retry, which for an
unlimited retry means a hung OS.  If you limit the number of retries
then in the best case it's just lots of wasted CPU cycles.

And an audit would still not ensure safety against future additions of
ESTALE.

And a simple audit won't find things like fuse, where the error comes
from outside the kernel.  Fixing that is not trivial either.  Turning
ESTALE into some other error prevents looping but breaks the return
value.

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/