[IBAL] IBAL has two reserved CID values that it stores in the QPs - AL_INVALID_CID...
authorleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Wed, 2 Jul 2008 13:32:47 +0000 (13:32 +0000)
committerleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Wed, 2 Jul 2008 13:32:47 +0000 (13:32 +0000)
commit58b1709ec8ce5c84a6afdbc4dc5e0a50be9065f0
treef95a96ec3553843046b3e10346df6dc84a99f94a
parent171d7d404beac7ec14b58384490be6b0f5105b1e
[IBAL] IBAL has two reserved CID values that it stores in the QPs - AL_INVALID_CID, meaning that there is no CEP associated with the QP but that one can be associated, and AL_RESERVED_CID, which means no CEP is associated, and none should be because the QP is being destroyed.

The code uses atomic operations to check for/set AL_INVALID_CID or AL_RESERVED_CID.  Since there are two possible 'special' values, atomics can't be used reliably.

There has been a report of this related to SRP and BSODs.

Additionally, the code would provide the destroy callback when destroying the CEP.  However, the CEP can be destroyed through different paths, and it's important to make sure the destroy callback is invoked always so that reference counts can be properly released.

This patch pushes all assignments and checks for special values into the CEP manager, protected by the CEP manager's lock that it holds when performing the CEP lookup.  It also changes the semantics of creation/destruction of the CEPs to provide the destroy callback when the CEP is created or bound to an object (the binding path is for the passive side of a connection).

Signed-off-by: Fab Tillier <ftillier@microsoft.com>
git-svn-id: svn://openib.tc.cornell.edu/gen1/trunk@1326 ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86
core/al/al_cm_cep.h
core/al/al_cm_qp.c
core/al/al_qp.c
core/al/al_qp.h
core/al/kernel/al_cm_cep.c
core/al/kernel/al_ndi_cm.c
core/al/kernel/al_ndi_cm.h
core/al/kernel/al_proxy_cep.c
core/al/kernel/al_proxy_ndi.c
core/al/user/ual_cm_cep.c