diff options
author | Steve Wise <swise@opengridcomputing.com> | 2016-12-22 15:40:36 (GMT) |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2017-02-01 07:33:09 (GMT) |
commit | 0bd3cb8d470b7fdf0fbf677fcc19da915e740edc (patch) | |
tree | f061921b58f9a1f2ebc4c3546d6ef7eb59ee8436 /drivers/infiniband/hw/i40iw | |
parent | cb1d48f55a6dd1ad04caec1c140c2a136eb99206 (diff) | |
download | linux-0bd3cb8d470b7fdf0fbf677fcc19da915e740edc.tar.xz |
iw_cxgb4: free EQ queue memory on last deref
commit c12a67fec8d99bb554e8d4e99120d418f1a39c87 upstream.
Commit ad61a4c7a9b7 ("iw_cxgb4: don't block in destroy_qp awaiting
the last deref") introduced a bug where the RDMA QP EQ queue memory
(and QIDs) are possibly freed before the underlying connection has been
fully shutdown. The result being a possible DMA read issued by HW after
the queue memory has been unmapped and freed. This results in possible
WR corruption in the worst case, system bus errors if an IOMMU is in use,
and SGE "bad WR" errors reported in the very least. The fix is to defer
unmap/free of queue memory and QID resources until the QP struct has
been fully dereferenced. To do this, the c4iw_ucontext must also be kept
around until the last QP that references it is fully freed. In addition,
since the last QP deref can happen in an IRQ disabled context, we need
a new workqueue thread to do the final unmap/free of the EQ queue memory.
Fixes: ad61a4c7a9b7 ("iw_cxgb4: don't block in destroy_qp awaiting the last deref")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/infiniband/hw/i40iw')
0 files changed, 0 insertions, 0 deletions