> Good catch, although, I think we can simplify the fix to the patch below > (completely untested). Please let me know if this solves the issue for you. > > drivers/infiniband/core/cm.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/infiniband/core/cm.c b/drivers/infiniband/core/cm.c > index 1d9616b..79da42d 100644 > --- a/drivers/infiniband/core/cm.c > +++ b/drivers/infiniband/core/cm.c > @@ -888,6 +888,8 @@ retest: > NULL, 0, NULL, 0); > break; > case IB_CM_ESTABLISHED: > + if (cm_id->lap_state == IB_CM_LAP_SENT) > + ib_cancel_mad(cm_id_priv->av.port->mad_agent, > cm_id_priv->msg); > spin_unlock_irq(&cm_id_priv->lock); > ib_send_cm_dreq(cm_id, NULL, 0); > goto retest; > >
Hi Sean I tried this and it doesn't fix the issue in my test. It operates only in IB_CM_ESTABLISHED but in my tests the order of operations in client side is 1. rdma_connect() was called 2. lap was sent (for which apr will never be received - according to test case) 3. rdma_disconnect() was called 4. rdma_destroy_id() was called (state here is IB_CM_DREQ_SENT) -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
