Commit:     c64e80d55db81df22a7f25b75ab4ba4c55db4749
Parent:     9706501e43a80ce48b319214a0a9e562deded35b
Author:     Jeff Layton <[EMAIL PROTECTED]>
AuthorDate: Wed Feb 6 11:34:13 2008 -0500
Committer:  J. Bruce Fields <[EMAIL PROTECTED]>
CommitDate: Sun Feb 10 18:09:36 2008 -0500

    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 <[EMAIL PROTECTED]>
    Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
 fs/lockd/svclock.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
index 82db7b3..fe9bdb4 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. */
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to