[ofw] [PATCH 4/9] dapl-2.0: ucm: UD mode, active side cm object released to soon, the RTU could be lost.

Davis, Arlin R arlin.r.davis at intel.com
Wed May 19 11:25:19 PDT 2010


Will see following message with DAPL_DBG_TYPE set for Errors & Warnings (0x3):
ucm_recv: NO MATCH op REP 0x120 65487 i0x60005e c0x60005e < 0xd2 19824 0x60006a

The cm object was released on the active side after the connection
was established, RTU sent. This is a problem if the RTU is lost
and the remote side retries the REPLY. The RTU is never resent.
Keep the cm object until the EP is destroyed.

Signed-off-by: Arlin Davis <arlin.r.davis at intel.com>
---
 dapl/openib_ucm/cm.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/dapl/openib_ucm/cm.c b/dapl/openib_ucm/cm.c
index c82147e..94af988 100644
--- a/dapl/openib_ucm/cm.c
+++ b/dapl/openib_ucm/cm.c
@@ -1143,10 +1143,6 @@ ud_bail:
 				(DAT_COUNT)ntohs(cm->msg.p_size),
 				(DAT_PVOID *)cm->msg.p_data,
 				(DAT_PVOID *)&xevent);
-
-		/* release cm_ptr, EP refs will prevent destroy */
-		dapli_cm_free(cm);
-				
 	} else
 #endif
 	{
@@ -1310,10 +1306,6 @@ static void ucm_accept_rtu(dp_ib_cm_handle_t cm, ib_cm_msg_t *msg)
 				(DAT_COUNT)ntohs(cm->msg.p_size),
 				(DAT_PVOID *)cm->msg.p_data,
 				(DAT_PVOID *)&xevent);
-
-                /* done with CM object, EP ref will hold object for pdata */
-		dapli_cm_free(cm);
-		
 	} else {
 #endif
 		dapls_cr_callback(cm, IB_CME_CONNECTED, NULL, 0, cm->sp);
-- 
1.5.2.5




More information about the ofw mailing list