We think we have a fix - however we definitely need some folks to
review. This does appear to solve the reproducible issue as we were
seeing it.
>From 627028f01dae67882061c533236ac3f1f00c70c3 Mon Sep 17 00:00:00 2001
From: Aaron Wiebe <aaronw@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 27 Mar 2008 16:53:04 -0400
Subject: [PATCH] Fix an issue where an NLM CANCEL would desync VFS
In the condition where a process is waiting on an NLM
lock, and the process receives a signal, an NLM CANCEL
is sent to the nfs server. In that case, VFS would
maintain an entry in its blocked list. After the
signal handler returns, NLM re-requests the lock.
VFS is not being properly notified to release the local
lock when the NLM CANCEL is processed. When NLM
re-requests the lock, blocks, and then a GRANTED
callback is received, the process ends up blocking on
its original (cancelled) lock.
Tell VFS to clear the lock request after a CANCEL is
completed.
Signed-off-by: Aaron Wiebe <aaronw@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Brandon Seibel <brandon.seibel@xxxxxxxxxxxxxxxxxxxx>
---
fs/lockd/clntproc.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c
index b6b74a6..6a1b80c 100644
--- a/fs/lockd/clntproc.c
+++ b/fs/lockd/clntproc.c
@@ -687,6 +687,10 @@ static int nlmclnt_cancel(struct nlm_host *host,
int block, struct file_lock *fl
return -ENOMEM;
req->a_flags = RPC_TASK_ASYNC;
+ /* set the lock type to F_UNLCK for vfs, so once the cancel has
+ * completed, the vfs blocked list will be updated accordingly
+ */
+ fl->fl_type = F_UNLCK;
nlmclnt_setlockargs(req, fl);
req->a_args.block = block;
--
1.5.3.4
--
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
