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: <20120423143345.0388fcc5@tlielax.poochiereds.net>
Date:	Mon, 23 Apr 2012 14:33:45 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Steve Dickson <SteveD@...hat.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, miklos@...redi.hu,
	viro@...IV.linux.org.uk, hch@...radead.org,
	michael.brantley@...haw.com, sven.breuner@...m.fraunhofer.de,
	chuck.lever@...cle.com, pstaubach@...grid.com, malahal@...ibm.com,
	bfields@...ldses.org, trond.myklebust@....uio.no, rees@...ch.edu
Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors
 from getattr call

On Mon, 23 Apr 2012 14:06:46 -0400
Steve Dickson <SteveD@...hat.com> wrote:


> > 
> > It'd be preferable to me if we didn't require a new error code, but if
> > different filesystems require different semantics from the VFS on an
> > ESTALE return, then that is one way to achieve it.
> > 
> Well I thought the use of the fs_flags to register for this type
> of semantics was a good one...
> 

The problem with that is that you don't have a way to know whether the
fs wants you to retry or not on a lookup. When you get back an ESTALE
on a lookup, then that's all you have. You don't know what fs was
involved. The ERETRYLOOKUP return solves that case nicely.

The problem with the ERETRYLOOKUP idea in other codepaths is that we'll
have a bunch of this kind of crap all over the place in the vfs code:

    return rc == -ERETRYLOOKUP ? -ESTALE : rc;

...in order to deal with those codepaths that might call down into the
fs, get that error back and then not actually be able to retry. For
instance, vfs_getattr is called from both vfs_fstat and vfs_fstatat.
The latter can and should retry on an ESTALE, but the former cannot.

That's a relatively simple case though. The real PITA will be stuff
like the inode_permission codepaths which branch out very widely. It'll
be hard to ensure that ERETRYLOOKUP doesn't leak out from there.

Another possibility is a hybrid approach. Have only the lookup codepath
return ERETRYLOOKUP to indicate that the fs wants to retry more than
once. Once you have a pointer to the sb, then you can look at the FS_*
flag and use that to indicate that you want to retry on an ESTALE
return.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ