[PATCH 3.13 186/198] nfs: Fix cache_validity check in nfs_write_pageuptodate()
Kamal Mostafa
kamal at canonical.com
Tue Jul 15 21:30:56 UTC 2014
3.13.11.5 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Scott Mayhew <smayhew at redhat.com>
commit 18dd78c427513fb0f89365138be66e6ee8700d1b upstream.
NFS_INO_INVALID_DATA cannot be ignored, even if we have a delegation.
We're still having some problems with data corruption when multiple
clients are appending to a file and those clients are being granted
write delegations on open.
To reproduce:
Client A:
vi /mnt/`hostname -s`
while :; do echo "XXXXXXXXXXXXXXX" >>/mnt/file; sleep $(( $RANDOM % 5 )); done
Client B:
vi /mnt/`hostname -s`
while :; do echo "YYYYYYYYYYYYYYY" >>/mnt/file; sleep $(( $RANDOM % 5 )); done
What's happening is that in nfs_update_inode() we're recognizing that
the file size has changed and we're setting NFS_INO_INVALID_DATA
accordingly, but then we ignore the cache_validity flags in
nfs_write_pageuptodate() because we have a delegation. As a result,
in nfs_updatepage() we're extending the write to cover the full page
even though we've not read in the data to begin with.
Signed-off-by: Scott Mayhew <smayhew at redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust at primarydata.com>
[ kamal: backport to 3.13-stable ]
Signed-off-by: Kamal Mostafa <kamal at canonical.com>
---
fs/nfs/write.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/nfs/write.c b/fs/nfs/write.c
index 6a85038..af7c958 100644
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -911,9 +911,11 @@ static bool nfs_write_pageuptodate(struct page *page, struct inode *inode)
{
if (nfs_have_delegated_attributes(inode))
goto out;
- if (NFS_I(inode)->cache_validity & (NFS_INO_INVALID_DATA|NFS_INO_REVAL_PAGECACHE))
+ if (NFS_I(inode)->cache_validity & NFS_INO_REVAL_PAGECACHE)
return false;
out:
+ if (NFS_I(inode)->cache_validity & NFS_INO_INVALID_DATA)
+ return false;
return PageUptodate(page) != 0;
}
--
1.9.1
More information about the kernel-team
mailing list