diff options
author | Mike Marciniszyn <mike.marciniszyn@intel.com> | 2013-02-07 20:47:51 +0000 |
---|---|---|
committer | Roland Dreier <roland@purestorage.com> | 2013-02-14 17:04:18 -0800 |
commit | bcc9b67a5b65ec2e1ec5371226a729ec1b380860 (patch) | |
tree | 23edbc2c2964ee07d5c96c4ab3f5e697ad248fa6 /drivers/infiniband/ulp | |
parent | 836dc9e3fbbab0c30aa6e664417225f5c1fb1c39 (diff) | |
download | talos-obmc-linux-bcc9b67a5b65ec2e1ec5371226a729ec1b380860.tar.gz talos-obmc-linux-bcc9b67a5b65ec2e1ec5371226a729ec1b380860.zip |
IB/qib: Fix QP locate/remove race
remove_qp() can execute concurrently with a qib_lookup_qpn() on
another CPU, which in of itself, is ok, given the RCU locking.
The issue is that remove_qp() NULLs out the qp->next field so that a
qib_lookup_qpn() might fail to find a qp if it occurs after the one
that is being deleted. This is a momentary issue and subsequent
qib_lookup_qpn() calls would find the qp's since the search restarts
from the bucket head. At scale, the issue might causes dropped
packets and unnecessary retransmissions.
The fix just deletes the qp->next NULL assignment to prevent the
remove_qp() from hiding qp's from qib_lookup_qpn().
Reviewed-by: Dean Luick <dean.luick@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
Diffstat (limited to 'drivers/infiniband/ulp')
0 files changed, 0 insertions, 0 deletions