There exists a problem in the code that was easily reproducible prior
to the commit b757144fd77cf5512f5b60179ba5ca8dcc5184b4 ("NFSv4 Be less
aggressive about returning delegations"). The same code is used during
delegation return and is still reproducible (with highly coordinated
setup of triggering just the right actions).
The problem lies in the call of nfs4_lock_delegation_recall(). In the
nutshell, when the LOCK op gets an error such as ERR_GRACE, the error
is unhanded which leaves the client in incorrect state assuming that
it has 'successfully' acquired a lock that was locally acquired while
holding a delegation.
I believe the problem stems from the fact that
nfs4_lock_delegation_recall(), unlike normal version of LOCK
nfs4_proc_getlk(), lacks the do { handle_error(do_proc())} while(err)
structure.
I believe the problem should be fixed by something like the following:
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index 6ca0c8e..78d088c 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5936,11 +5936,12 @@ int nfs4_lock_delegation_recall(struct
file_lock *fl, struct nfs4_state *state,
struct nfs_server *server = NFS_SERVER(state->inode);
int err;
- err = nfs4_set_lock_state(state, fl);
- if (err != 0)
- return err;
- err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
- return nfs4_handle_delegation_recall_error(server, state, stateid, err);
+ do {
+ err = nfs4_handle_delegation_recall_error(server, state,
+ stateid, _nfs4_do_setlk(state, F_SETLK, fl,
+ NFS_LOCK_NEW));
+ } while (err == -EAGAIN);
+ return err;
}
struct nfs_release_lockowner_data {
Is this an acceptable solution?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
