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: <1334604785.2879.23.camel@lade.trondhjem.org>
Date:	Mon, 16 Apr 2012 19:33:05 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Jeff Layton <jlayton@...hat.com>
CC:	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>,
	"miklos@...redi.hu" <miklos@...redi.hu>,
	"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 Mon, 2012-04-16 at 13:46 -0400, Jeff Layton wrote:
> The question about looping indefinitely really comes down to:
> 
> 1) is a persistent ESTALE in conjunction with a successful lookup a
> situation that we expect to be temporary. i.e. will the admin at some
> point be able to do something about it? If not, then there's no point
> in continuing to retry. Again, this is a situation that *really* should
> not happen if the filesystem is doing the right thing.
> 
> 2) If the admin can't do anything about it, is it reasonable to expect
> that users can send a fatal signal to hung applications if this
> situation occurs.
> 
> We expect that that's ok in other situations to resolve hung
> applications, so I'm not sure I understand why it wouldn't be
> acceptable here...

There are definitely potentially persistent pathological situations that
the filesystem can't do anything about. If the point of origin for your
pathname (for instance your current directory in the case of a relative
pathname) is stale, then no amount of looping is going to help you to
recover.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com