8d8ac86564
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> |
||
---|---|---|
.. | ||
addr.c | ||
agent.c | ||
agent.h | ||
cache.c | ||
cm_msgs.h | ||
cm.c | ||
cma.c | ||
core_priv.h | ||
device.c | ||
fmr_pool.c | ||
iwcm.c | ||
iwcm.h | ||
mad_priv.h | ||
mad_rmpp.c | ||
mad_rmpp.h | ||
mad.c | ||
Makefile | ||
multicast.c | ||
packer.c | ||
sa_query.c | ||
sa.h | ||
smi.c | ||
smi.h | ||
sysfs.c | ||
ucm.c | ||
ucma.c | ||
ud_header.c | ||
umem.c | ||
user_mad.c | ||
uverbs_cmd.c | ||
uverbs_main.c | ||
uverbs_marshall.c | ||
uverbs.h | ||
verbs.c |