If an 'open' of a file in an NFSv4 filesystem finds that the dentry is in cache, but the inode is stale (on the server), the dentry will not be re-validated immediately and may cause ESTALE to be returned to user-space. For a non-create 'open', do_last() calls lookup_fast() and on success will eventually call may_open() which calls into nfs_permission(). If nfs_permission() makes the ACCESS call to the server it will get NFS4ERR_STALE, resulting in ESTALE from may_open() and thence from do_last(). The retry-on-ESTALE in filename_lookup() will repeat exactly the same process because nothing in this path will invalidate the dentry due to the inode being stale, so the ESTALE will be returned. lookup_fast() calls ->d_revalidate(), but for an OPEN on an NFSv4 filesystem, that will succeed for regular files: /* Let f_op->open() actually open (and revalidate) the file */ Unfortunately in the case of a STALE inode, f_op->open() never gets called. If we teach nfs4_lookup_revalidate() to report a failure on NFS_STALE() inodes, then the dentry will be invalidated and a full lookup will be attempted. The ESTALE errors go away. While I think this fix is correct, I'm not convinced that it is sufficient, particularly if lookupcache=none. The current code will fail an "open" is nfs_permission() fails, without having performed a LOOKUP. i.e. it will use the cache. nfs_lookup_revalidate will force a lookup before the permission check if NFS_MOUNT_LOOKUP_CACHE_NONE, but nfs4_lookup_revalidate will not. Signed-off-by: NeilBrown <neilb@xxxxxxx> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 4a3d4ef76127..4f7414afca27 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1563,6 +1563,8 @@ static int nfs4_lookup_revalidate(struct dentry *dentry, unsigned int flags) /* We cannot do exclusive creation on a positive dentry */ if (flags & LOOKUP_EXCL) goto no_open_dput; + if (NFS_STALE(inode)) + goto no_open_dput; /* Let f_op->open() actually open (and revalidate) the file */ ret = 1;
Attachment:
signature.asc
Description: PGP signature
