[PATCH 4.2 079/134] NFS: Dont let the ctime override attribute barriers.

From: Greg Kroah-Hartman
Date: Sat Sep 26 2015 - 17:02:26 EST

4.2-stable review patch. If anyone has any objections, please let me know.


From: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>

commit 7c2dad99d60c86ec686b3bfdcb787c450a7ea89f upstream.

Chuck reports seeing cases where a GETATTR that happens to race
with an asynchronous WRITE is overriding the file size, despite
the attribute barrier being set by the writeback code.

The culprit turns out to be the check in nfs_ctime_need_update(),
which sees that the ctime is newer than the cached ctime, and
assumes that it is safe to override the attribute barrier.
This patch removes that override, and ensures that attribute
barriers are always respected.

Reported-by: Chuck Lever <chuck.lever@xxxxxxxxxx>
Fixes: a08a8cd375db9 ("NFS: Add attribute update barriers to NFS writebacks")
Signed-off-by: Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>

fs/nfs/inode.c | 8 --------
1 file changed, 8 deletions(-)

--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -1273,13 +1273,6 @@ static int nfs_check_inode_attributes(st
return 0;

-static int nfs_ctime_need_update(const struct inode *inode, const struct nfs_fattr *fattr)
- if (!(fattr->valid & NFS_ATTR_FATTR_CTIME))
- return 0;
- return timespec_compare(&fattr->ctime, &inode->i_ctime) > 0;
static atomic_long_t nfs_attr_generation_counter;

static unsigned long nfs_read_attr_generation_counter(void)
@@ -1428,7 +1421,6 @@ static int nfs_inode_attrs_need_update(c
const struct nfs_inode *nfsi = NFS_I(inode);

return ((long)fattr->gencount - (long)nfsi->attr_gencount) > 0 ||
- nfs_ctime_need_update(inode, fattr) ||
((long)nfsi->attr_gencount - (long)nfs_read_attr_generation_counter() > 0);

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/