[IBAL] Fix CEP destruction.
authorleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Wed, 9 Jul 2008 10:39:14 +0000 (10:39 +0000)
committerleonidk <leonidk@ad392aa1-c5ef-ae45-8dd8-e69d62a5ef86>
Wed, 9 Jul 2008 10:39:14 +0000 (10:39 +0000)
commitc12aee26f688e2e1f4e1c7b46358699d7625be43
tree29e62433e7c6ca433b7572ca35ac8b2f04679a60
parentcf3087503d715e490de16fc11f5497774a702d99
[IBAL] Fix CEP destruction.

In my previous patch "Fix race reading/setting connection ID" I incorrectly stated that the patch changed the semantics of creation/destruction of the CEPs by providing the destroy callback at CEP creation time.  It didn't, but this patch does.

Note that it also backs out the "Cleanup CEPs after child objects have been destroyed" changes, as those actually introduced the following issue:

UM listen CEPs are not tracked in AL's handle table, but can queue MADs which take a reference on the AL instance.  AL's destroying callback must cleanup the CEPs to free the MADs in order for the ref count to reach zero.

The root problem, and the iterations of the fix that are apparent in the patch sequence has to do with race conditions cleaning up QPs while CM messages are being received and processed.  First there was the issue of the CID stored in the QP having two reserved states and races checking/assigning this value.  This was fixed (successfully) by pushing checks into the CEP manager, protected by the CEP manager's spinlock.  Next was the issue that a reference on the QP is taken when the CEP is bound to a QP, but if AL was destroyed the CEP cleanup in AL would blow away the CEPs before the QPs were done being destroyed.  This would leak a reference count on the QP since the CEP was destroyed without a destroy callback.  The change that added a cleanup callback to AL was the first (failed) attempt to fix this (for the reasons listed above).  This patch is the successful attempt to fix this, as it sets the destroy callback at creation time.  No matter what path destroys the CEP, if a destroy callback was taken (because some object has a reference for the CEP), the destroy callback will always be invoked.

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