Admittedly, I'm in this situation due to working on broken device
code, but I think the patch below addresses a valid problem.
Against 2.6.26-rc8.
Consider a very slow link and an impatient client. It does
rdma_connect(), then times out at the application layer while the
IW_CM_STATE is still CONN_SENT. It calls rdma_reject() and finally
rdma_destroy_id(). That leads to the BUG() in destroy_cm_id().
Note the call to rdma_reject() is necessary to avoid hanging at the
top of destroy_cm_id(), waiting for the IWCM_F_CONNECT_WAIT bit to
be cleared.
-- Pete
----------------------------------------------------------------
An application may call rdma_destroy_id() when in the CONN_SENT
state. This should also send a reject to the provider, just like
for the CONN_RECV case. It currently BUG()s without this patch.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
---
drivers/infiniband/core/iwcm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/core/iwcm.c b/drivers/infiniband/core/iwcm.c
index 81c9195..acffdea 100644
--- a/drivers/infiniband/core/iwcm.c
+++ b/drivers/infiniband/core/iwcm.c
@@ -354,6 +354,7 @@ static void destroy_cm_id(struct iw_cm_id *cm_id)
case IW_CM_STATE_CLOSING:
cm_id_priv->state = IW_CM_STATE_DESTROYING;
break;
+ case IW_CM_STATE_CONN_SENT:
case IW_CM_STATE_CONN_RECV:
/*
* App called destroy before/without calling accept after
@@ -363,7 +364,6 @@ static void destroy_cm_id(struct iw_cm_id *cm_id)
*/
cm_id_priv->state = IW_CM_STATE_DESTROYING;
break;
- case IW_CM_STATE_CONN_SENT:
case IW_CM_STATE_DESTROYING:
default:
BUG();
--
1.5.5.1
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
