We've observed that if the NFS client experiences a network partition and
the server revokes the client's state, the client may not revalidate cached
data for an open file during recovery. If the file is extended by a second
client during this network partition, the first client will correctly
update the file's size and attributes during recovery, but another
extending write will discard the second client's data.
In the case where another client opened the file during the network
partition and the server revoked the first client's state, the recovery can
forego optimizations and instead attempt to avoid corruption.
It's a little tricky to solve this in a per-file way during recovery
without plumbing arguments or introducing new flags. This patch side-steps
the per-file complexity by simply checking if the client is within a
NOGRACE recovery window, and if so, invalidates data during the open
recovery.
Signed-off-by: Benjamin Coddington <bcodding@xxxxxxxxxx>
---
fs/nfs/nfs4proc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 40d749f29ed3..b9e1e817a723 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -2604,7 +2604,9 @@ static int nfs4_run_open_task(struct nfs4_opendata *data,
static int _nfs4_recover_proc_open(struct nfs4_opendata *data)
{
+ struct inode *inode = d_inode(data->dentry);
struct inode *dir = d_inode(data->dir);
+ struct nfs_openargs *o_arg = &data->o_arg;
struct nfs_openres *o_res = &data->o_res;
int status;
@@ -2614,6 +2616,12 @@ static int _nfs4_recover_proc_open(struct nfs4_opendata *data)
nfs_fattr_map_and_free_names(NFS_SERVER(dir), &data->f_attr);
+ if (test_bit(NFS4CLNT_RECLAIM_NOGRACE, &o_arg->server->nfs_client->cl_state)) {
+ spin_lock(&inode->i_lock);
+ nfs_set_cache_invalid(inode, NFS_INO_INVALID_DATA);
+ spin_unlock(&inode->i_lock);
+ }
+
if (o_res->rflags & NFS4_OPEN_RESULT_CONFIRM)
status = _nfs4_proc_open_confirm(data);
--
2.31.1
