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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 23 Apr 2012 11:02:32 -0400
From:	Chuck Lever <chuck.lever@...cle.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Jeff Layton <jlayton@...hat.com>,
	Malahal Naineni <malahal@...ibm.com>,
	Steve Dickson <SteveD@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org, michael.brantley@...haw.com,
	sven.breuner@...m.fraunhofer.de, pstaubach@...grid.com,
	trond.myklebust@....uio.no, rees@...ch.edu
Subject: Re: [PATCH RFC v3] vfs: make fstatat retry once on ESTALE errors from getattr call


On Apr 23, 2012, at 10:51 AM, Miklos Szeredi wrote:

> "J. Bruce Fields" <bfields@...ldses.org> writes:
> 
>> 
>> I also wonder whether it would be making too many assumptions about the
>> server or filesystem: just because ordinary posix interfaces don't allow
>> atomic replacement of a whole directory tree doesn't mean the server
>> might not have some way to do it.
> 
> Exactly because posix limits the atomic replacement to empty directories
> is that this feature is not useful and is why linux can get away with
> the dead directory behavior in this case.  And thinking about fixing
> this in NFS is completely pointless since no one will rely on the atomic
> replacement behavior.  Fixing local filesystems is also pointless for
> the same reason.
> 
> Atomic replacement of whole directory trees would indeed be more useful,
> but it's highly unlikely to be used anywhere since applications relying
> on this feature would be limited to special filesystems that allow this.

The cases I can think of have to do with file system restore, file system and block device snapshots, and so on.  This type of use case may not practical on today's Linux server, but they are a reality for anyone using high-end NFS storage.

> So my statement is "ENOENT is equivalent to ESTALE if already retrying
> path lookup with LOOKUP_REVAL on any operation that takes an parent
> directory and a name (lookup, create, link, unlink, symlink, mkdir,
> rmdir, mknod, rename)."
> 
> This equivalence is in the sense that it doesn't change behavior
> compared to local filesystems.
> 
> For other operations ENOENT is not equivalent to ESTALE.
> 
> Thanks,
> Miklos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]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/