summaryrefslogtreecommitdiffstats
path: root/Documentation/devicetree/bindings/arm/sunxi.yaml
diff options
context:
space:
mode:
authorTyrel Datwyler <tyreld@linux.ibm.com>2020-10-24 19:13:55 -0500
committerMartin K. Petersen <martin.petersen@oracle.com>2020-10-26 17:14:40 -0400
commit665e0224a3d76f36da40bd9012270fa629aa42ed (patch)
tree2e2ad3b4d79b717de0df8d5985b8a917fdd4f608 /Documentation/devicetree/bindings/arm/sunxi.yaml
parent2f4843b172c2c0360ee7792ad98025fae7baefde (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 'Documentation/devicetree/bindings/arm/sunxi.yaml')
0 files changed, 0 insertions, 0 deletions