Windows: cm_MergeStatus avoid lock recursion

It is possible for cm_MergeStatus() to be called while the
cm_buf_t.mx is already held.  If it is a panic occurs.  Test for
refcount == 0 before acquiring the lock in addition to afterwards.
If the refcount is not zero, then we do not need to acquire the
lock in any case.

Change-Id: I1b73a03f4745e524d7fdf8f9b231b420895ff0fa
Reviewed-on: http://gerrit.openafs.org/10297
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>

diff --git a/src/WINNT/afsd/cm_scache.c b/src/WINNT/afsd/cm_scache.c
index 3595e96..d939554 100644 (file)
--- a/src/WINNT/afsd/cm_scache.c
+++ b/src/WINNT/afsd/cm_scache.c
@@ -1975,7 +1975,8 @@ long cm_MergeStatus(cm_scache_t *dscp,
              * so leave it in place.
              */
             if (cm_FidCmp(&scp->fid, &bp->fid) == 0 &&
-                 lock_TryMutex(&bp->mx)) {
+                bp->refCount == 0 &&
+                lock_TryMutex(&bp->mx)) {
                 if (bp->refCount == 0 &&
                     !(bp->flags & (CM_BUF_READING | CM_BUF_WRITING | CM_BUF_DIRTY)) &&
                     !(bp->qFlags & CM_BUF_QREDIR)) {