]> www.pilppa.org Git - linux-2.6-omap-h63xx.git/commitdiff
[PATCH] NLM: Ensure we do not Oops in the case of an unlock
authorTrond Myklebust <Trond.Myklebust@netapp.com>
Tue, 14 Mar 2006 05:20:49 +0000 (21:20 -0800)
committerLinus Torvalds <torvalds@g5.osdl.org>
Tue, 14 Mar 2006 15:57:18 +0000 (07:57 -0800)
In theory, NLM specs assure us that the server will only reply LCK_GRANTED or
LCK_DENIED_GRACE_PERIOD to our NLM_UNLOCK request.

In practice, we should not assume this to be the case, and the code will
currently Oops if we do.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
fs/lockd/clntproc.c

index 220058d8616d143d7afb386a395b818b60a855aa..970b6a6aa3378e6f7cf6239d6a0f2700e5f4e7ff 100644 (file)
@@ -662,12 +662,18 @@ nlmclnt_unlock(struct nlm_rqst *req, struct file_lock *fl)
         * reclaimed while we're stuck in the unlock call. */
        fl->fl_u.nfs_fl.flags &= ~NFS_LCK_GRANTED;
 
+       /*
+        * Note: the server is supposed to either grant us the unlock
+        * request, or to deny it with NLM_LCK_DENIED_GRACE_PERIOD. In either
+        * case, we want to unlock.
+        */
+       do_vfs_lock(fl);
+
        if (req->a_flags & RPC_TASK_ASYNC) {
                status = nlmclnt_async_call(req, NLMPROC_UNLOCK,
                                        &nlmclnt_unlock_ops);
                /* Hrmf... Do the unlock early since locks_remove_posix()
                 * really expects us to free the lock synchronously */
-               do_vfs_lock(fl);
                if (status < 0) {
                        nlmclnt_release_lockargs(req);
                        kfree(req);
@@ -680,7 +686,6 @@ nlmclnt_unlock(struct nlm_rqst *req, struct file_lock *fl)
        if (status < 0)
                return status;
 
-       do_vfs_lock(fl);
        if (resp->status == NLM_LCK_GRANTED)
                return 0;