From: phil <phil>
Date: Sun, 22 Feb 2004 04:19:29 +0000 (+0000)
Subject: 1. When one thread enqueues and another thread matches, the matching
X-Git-Tag: v1_7_0_51~2^7~78
X-Git-Url: https://git.whamcloud.com/?a=commitdiff_plain;h=fa8216874d829adb57daa539213771fe291c1558;p=fs%2Flustre-release.git

1. When one thread enqueues and another thread matches, the matching
thread can get the lock before the enqueueing thread updates the lock
value block.  The correct fix is to do the granting inside of the
completion AST -- which can then be wrapped as appropriate to handle
the LVB mechanics -- but that's higher risk than I want right now.

Instead, I added a temporary LDLM_FL_CAN_MATCH flag, which gets set
only after the enqueueing thread is finished.  Threads trying to match
will wait for this flag to be set after the lock is granted.

2. Fixes a fencepost error in the KMS calculation; a lock on [x, y]
actually protects a file of y + 1 bytes, not y bytes.

3. I spotted that ldlm_completion_ast might not call wake_up in
certain cases, but I think that's a theoretical concern.  Fixed by
checking a different set of flags.
---

diff --git a/lustre/obdfilter/filter_lvb.c b/lustre/obdfilter/filter_lvb.c
index 17dc35d..254a3fb 100644
--- a/lustre/obdfilter/filter_lvb.c
+++ b/lustre/obdfilter/filter_lvb.c
@@ -87,6 +87,11 @@ static int filter_lvbo_init(struct ldlm_resource *res)
  out:
         if (oa)
                 obdo_free(oa);
+        if (rc && lvb != NULL) {
+                OBD_FREE(lvb, sizeof(*lvb));
+                res->lr_lvb_data = NULL;
+                res->lr_lvb_len = 0;
+        }
         up(&res->lr_lvb_sem);
         return rc;
 }