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:	Mon, 16 Apr 2012 19:05:48 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.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, 16 Apr 2012 20:25:06 +0000
"Myklebust, Trond" <Trond.Myklebust@...app.com> wrote:

> On Mon, 2012-04-16 at 15:43 -0400, Jeff Layton wrote:
> > On Mon, 16 Apr 2012 19:33:05 +0000
> > "Myklebust, Trond" <Trond.Myklebust@...app.com> wrote:
> > 
> > > 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.
> > > 
> > 
> > Ok -- Peter pretty much said something similar. Retrying indefnitely
> > when the lookup returns ESTALE probably won't help. I'm ok with
> > basically letting the VFS continue to do what it does there already. If
> > it gets an ESTALE, it tries again with LOOKUP_REVAL set and then gives
> > up if that doesn't work.
> > 
> > If however, the operation itself keeps returning ESTALE, are we OK to
> > retry indefinitely assuming that we'll break out of the loop on fatal
> > signals?
> >
> > For example, something like the v2 patch I sent a little while ago?
> 
> 
> Won't something like fstatat(AT_FDCWD, "", &stat, AT_EMPTY_PATH) risk
> looping forever there, or am I missing something?
> 

To make sure I understand, that should be "shortcut" for a lookup of the
cwd?

So I guess the concern is that you'd do the above and get a successful
lookup since you're just going to get back the cwd. At that point,
you'd attempt the getattr and get ESTALE back. Then, you'd redo the
lookup with LOOKUP_REVAL set -- but since we're operating on the
cwd, we don't have a way to redo the lookup since we don't have a
pathname that we can look up again...

So yeah, I guess if you're sitting in a stale directory, something like
that could loop eternally.

Do you think the proposed check for fatal_signal_pending is enough to
mitigate such a problem? Or do we need to limit the number of retries
to address those sorts of loops?

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