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>
This commit is contained in:
Jeffrey Altman 2013-09-27 18:02:52 -04:00
parent 7efd785390
commit 4f266f14c0

View File

@ -1975,7 +1975,8 @@ long cm_MergeStatus(cm_scache_t *dscp,
* so leave it in place. * so leave it in place.
*/ */
if (cm_FidCmp(&scp->fid, &bp->fid) == 0 && if (cm_FidCmp(&scp->fid, &bp->fid) == 0 &&
lock_TryMutex(&bp->mx)) { bp->refCount == 0 &&
lock_TryMutex(&bp->mx)) {
if (bp->refCount == 0 && if (bp->refCount == 0 &&
!(bp->flags & (CM_BUF_READING | CM_BUF_WRITING | CM_BUF_DIRTY)) && !(bp->flags & (CM_BUF_READING | CM_BUF_WRITING | CM_BUF_DIRTY)) &&
!(bp->qFlags & CM_BUF_QREDIR)) { !(bp->qFlags & CM_BUF_QREDIR)) {