aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRoland Dreier <rolandd@cisco.com>2006-11-13 12:38:07 -0500
committerRoland Dreier <rolandd@cisco.com>2006-11-13 12:38:07 -0500
commit39798695b4bcc7b145f8910ca56195808d3a7637 (patch)
tree89f594faf977f800893f6fa59213e94e098df386
parentb26c791e9ca3365616d40836000285931ca033d0 (diff)
IB/mad: Fix race between cancel and receive completion
When ib_cancel_mad() is called, it puts the canceled send on a list and schedules a "flushed" callback from process context. However, this leaves a window where a receive completion could be processed before the send is fully flushed. This is fine, except that ib_find_send_mad() will find the MAD and return it to the receive processing, which results in the sender getting both a successful receive and a "flushed" send completion for the same request. Understandably, this confuses the sender, which is expecting only one of these two callbacks, and leads to grief such as a use-after-free in IPoIB. Fix this by changing ib_find_send_mad() to return a send struct only if the status is still successful (and not "flushed"). The search of the send_list already had this check, so this patch just adds the same check to the search of the wait_list. Signed-off-by: Roland Dreier <rolandd@cisco.com>
-rw-r--r--drivers/infiniband/core/mad.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c
index 493f4c65c7a2..a72bcea46ff6 100644
--- a/drivers/infiniband/core/mad.c
+++ b/drivers/infiniband/core/mad.c
@@ -1750,7 +1750,7 @@ ib_find_send_mad(struct ib_mad_agent_private *mad_agent_priv,
1750 */ 1750 */
1751 (is_direct(wc->recv_buf.mad->mad_hdr.mgmt_class) || 1751 (is_direct(wc->recv_buf.mad->mad_hdr.mgmt_class) ||
1752 rcv_has_same_gid(mad_agent_priv, wr, wc))) 1752 rcv_has_same_gid(mad_agent_priv, wr, wc)))
1753 return wr; 1753 return (wr->status == IB_WC_SUCCESS) ? wr : NULL;
1754 } 1754 }
1755 1755
1756 /* 1756 /*