rx: prevent connection channel assignment race
authorJeffrey Altman <jaltman@your-file-system.com>
Sun, 10 Jul 2011 02:43:45 +0000 (03:43 +0100)
committerDerrick Brashear <shadow@dementia.org>
Sun, 10 Jul 2011 13:50:29 +0000 (06:50 -0700)
commit99b43273c0203881ea3d2d50f0abf000cdc0b03e
tree3b88af942d6103521ffe51872d26bdc511b3b6ed
parent88b4e2e52799cfa5999cbc22873407ec8b77766a
rx: prevent connection channel assignment race

When rx was converted to use pthreads, the code that allocates
a call to a connection channel in rxi_ReceivePacket() was not
made thread safe.  The code prior to this patchset permitted a race
in the server connection case.  The rx_connection channel assignment
in rxi_ReceivePacket() and the call destruction in rxi_FreeCall()
and rxi_DestroyConnectionNoLock() did not consistently protect the
rx_connection channel array using the conn_call_lock.

This race could result in rxi_ReceivePacket() operating on a
rx_call which was disconnected from the previously assigned
rx_connection.

In addition, the code in rxi_ReceivePacket() that was intended
to protect the allocation of a call using rxi_NewCall() to the
connection channel array was racy with itself.

This patchset consistently applies the conn_call_lock to protect
the allocation / deallocation of calls to the connection channel
array and in the process simplifies the logic in rxi_ReceivePacket()
as it is no longer necessary to protect against a null call pointer
since the race can no longer be lost.

Change-Id: Id61b55b4d1d57a2b9b35ea942545ef4bdc8d33f3
Reviewed-on: http://gerrit.openafs.org/4963
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
src/rx/rx.c