NLM: don't requeue block if it was invalidated while GRANT_MSG was in flight

It's possible for lockd to catch a SIGKILL while a GRANT_MSG callback
is in flight. If this happens we don't want lockd to insert the block
back into the nlm_blocked list.

This helps that situation, but there's still a possible race. Fixing
that will mean adding real locking for nlm_blocked.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

1 files changed, 11 insertions, 0 deletions

diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
index 82db7b323b83..fe9bdb4a220c 100644
--- a/fs/lockd/svclock.c
+++ b/fs/lockd/svclock.c
@@ -795,6 +795,17 @@ static void nlmsvc_grant_callback(struct rpc_task *task, void *data)
 
         dprintk("lockd: GRANT_MSG RPC callback\n");
 
+        /* if the block is not on a list at this point then it has
+         * been invalidated. Don't try to requeue it.
+         *
+         * FIXME: it's possible that the block is removed from the list
+         * after this check but before the nlmsvc_insert_block. In that
+         * case it will be added back. Perhaps we need better locking
+         * for nlm_blocked?
+         */
+        if (list_empty(&block->b_list))
+                return;
+
         /* Technically, we should down the file semaphore here. Since we
          * move the block towards the head of the queue only, no harm
          * can be done, though. */