Rx: rxi_FreeCall conn_call_lock vs call->lock deadlock
authorJeffrey Altman <jaltman@your-file-system.com>
Fri, 20 Jan 2012 06:50:01 +0000 (01:50 -0500)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Tue, 3 Apr 2012 13:21:11 +0000 (06:21 -0700)
commit33185db16aca40a3bdbcb66caf994924220b5012
tree1e470c055f26c31d3f16ed5dfda05c2c033ee038
parent0ca4dc279a49141a63727134898c58f30ad15e8d
Rx: rxi_FreeCall conn_call_lock vs call->lock deadlock

The conn->conn_call_lock is held before call->lock in the lock
hierarchy which is violated within rxi_FreeCall(). While the
deadlock is rare, it is possible and has been experienced on
both Windows and Linux.

Change the signature of rxi_FreeCall to return 1 if it frees
the call and 0 if it does not.

Due to the lock hierarchy violation use MUTEX_TRYENTER()
to attempt to obtain the conn->conn_call_lock.  If the lock
cannot be obtained set the call state to dally and
return.  If the conn_call_lock can be obtained, behave as
we did before this patchset.

Only increment the callNumber if the original call->state
was dally or hold and the conn_call_lock could be obtained.
We must not increment the callNumber otherwise.  Doing so can
result in call numbers being skipped when the conn->call slot
is reused.

Change-Id: Ic10bd2004e9b06df319c2f2efaa0b37bcb90c896
Reviewed-on: http://gerrit.openafs.org/6443
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
src/rx/rx.c