diff options
author | Tyrel Datwyler <tyreld@linux.ibm.com> | 2020-10-24 19:13:55 -0500 |
---|---|---|
committer | Martin K. Petersen <martin.petersen@oracle.com> | 2020-10-26 17:14:40 -0400 |
commit | 665e0224a3d76f36da40bd9012270fa629aa42ed (patch) | |
tree | 2e2ad3b4d79b717de0df8d5985b8a917fdd4f608 /drivers/scsi/qla2xxx/qla_fw.h | |
parent | 2f4843b172c2c0360ee7792ad98025fae7baefde (diff) |
scsi: ibmvscsi: Fix potential race after loss of transport
After a loss of transport due to an adapter migration or crash/disconnect
from the host partner there is a tiny window where we can race adjusting
the request_limit of the adapter. The request limit is atomically
increased/decreased to track the number of inflight requests against the
allowed limit of our VIOS partner.
After a transport loss we set the request_limit to zero to reflect this
state. However, there is a window where the adapter may attempt to queue a
command because the transport loss event hasn't been fully processed yet
and request_limit is still greater than zero. The hypercall to send the
event will fail and the error path will increment the request_limit as a
result. If the adapter processes the transport event prior to this
increment the request_limit becomes out of sync with the adapter state and
can result in SCSI commands being submitted on the now reset connection
prior to an SRP Login resulting in a protocol violation.
Fix this race by protecting request_limit with the host lock when changing
the value via atomic_set() to indicate no transport.
Link: https://lore.kernel.org/r/20201025001355.4527-1-tyreld@linux.ibm.com
Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'drivers/scsi/qla2xxx/qla_fw.h')
0 files changed, 0 insertions, 0 deletions