IB/cm: Cancel pending LAP message when exiting IB_CM_ESTABLISH state
authorSean Hefty <sean.hefty@intel.com>
Thu, 3 Mar 2011 23:31:06 +0000 (23:31 +0000)
committerRoland Dreier <roland@purestorage.com>
Tue, 15 Mar 2011 17:56:12 +0000 (10:56 -0700)
commit8d8ac86564b616bc17054cbb6e727588da64c86b
treef17f09108b2fa639d5248120409e2fe562069545
parent29963437a48475036353b95ab142bf199adb909e
IB/cm: Cancel pending LAP message when exiting IB_CM_ESTABLISH state

This problem was reported by Moni Shoua <monis@mellanox.com> and Amir
Vadai <amirv@mellanox.com>:

When destroying a cm_id from a context of a work queue and if
the lap_state of this cm_id is IB_CM_LAP_SENT, we need to
release the reference of this id that was taken upon the send
of the LAP message.  Otherwise, if the expected APR message
gets lost, it is only after a long time that the reference
will be released, while during that the work handler thread is
not available to process other things.

It turns out that we need to cancel any pending LAP messages whenever
we transition out of the IB_CM_ESTABLISH state.  This occurs when
disconnecting - either sending or receiving a DREQ.  It can also
happen in a corner case where we receive a REJ message after sending
an RTU, followed by a LAP.  Add checks and cancel any outstanding LAP
messages in these three cases.

Canceling the LAP when sending a DREQ fixes the destroy problem
reported by Moni.  When a cm_id is destroyed in the IB_CM_ESTABLISHED
state, it sends a DREQ to the remote side to notify the peer that the
connection is going away.

Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
drivers/infiniband/core/cm.c
This page took 0.025075 seconds and 5 git commands to generate.