linux-stable.git/drivers/scsi, branch v5.4.76

scsi: ibmvscsi: Fix potential race after loss of transport

2020-11-10T11:37:30+00:00

[ Upstream commit 665e0224a3d76f36da40bd9012270fa629aa42ed ]

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 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: core: Don't start concurrent async scan on same host

2020-11-10T11:37:30+00:00

[ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ]

The current scanning mechanism is supposed to fall back to a synchronous
host scan if an asynchronous scan is in progress. However, this rule isn't
strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when
checking shost->async_scan. When scsi_scan_host() is called concurrently,
two async scans on same host can be started and a hang in do_scan_async()
is observed.

Fixes this issue by checking & setting shost->async_scan atomically with
shost->scan_mutex.

Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com
Cc: Christoph Hellwig 
Cc: Ewan D. Milne 
Cc: Hannes Reinecke 
Cc: Bart Van Assche 
Reviewed-by: Lee Duncan 
Reviewed-by: Bart Van Assche 
Signed-off-by: Ming Lei 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: qla2xxx: Fix crash on session cleanup with unload

2020-11-05T10:43:26+00:00

commit 50457dab670f396557e60c07f086358460876353 upstream.

On unload, session cleanup prematurely gave the signal for driver unload
path to advance.

Link: https://lore.kernel.org/r/20200929102152.32278-6-njavali@marvell.com
Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery")
Cc: stable@vger.kernel.org
Reviewed-by: Himanshu Madhani 
Signed-off-by: Quinn Tran 
Signed-off-by: Nilesh Javali 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: ufs: ufs-qcom: Fix race conditions caused by ufs_qcom_testbus_config()

2020-10-29T08:58:09+00:00

[ Upstream commit 89dd87acd40a44de8ff3358138aedf8f73f4efc6 ]

If ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from
ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync()
and ufshcd_hold() will cause a race condition. Fix this by removing the
unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().

Link: https://lore.kernel.org/r/1596975355-39813-3-git-send-email-cang@codeaurora.org
Reviewed-by: Hongwu Su 
Reviewed-by: Avri Altman 
Reviewed-by: Bean Huo 
Reviewed-by: Asutosh Das 
Signed-off-by: Can Guo 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: smartpqi: Avoid crashing kernel for controller issues

2020-10-29T08:58:09+00:00

[ Upstream commit 9e68cccc8ef7206f0bccd590378d0dca8f9b4f57 ]

Eliminate kernel panics when getting invalid responses from controller.
Take controller offline instead of causing kernel panics.

Link: https://lore.kernel.org/r/159622929306.30579.16523318707596752828.stgit@brunhilda
Reviewed-by: Scott Teel 
Reviewed-by: Scott Benesh 
Reviewed-by: Prasad Munirathnam 
Reviewed-by: Martin Wilck 
Signed-off-by: Kevin Barnett 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: qedi: Fix list_del corruption while removing active I/O

2020-10-29T08:58:08+00:00

[ Upstream commit 28b35d17f9f8573d4646dd8df08917a4076a6b63 ]

While aborting the I/O, the firmware cleanup task timed out and driver
deleted the I/O from active command list. Some time later the firmware
sent the cleanup task response and driver again deleted the I/O from
active command list causing firmware to send completion for non-existent
I/O and list_del corruption of active command list.

Add fix to check if I/O is present before deleting it from the active
command list to ensure firmware sends valid I/O completion and protect
against list_del corruption.

Link: https://lore.kernel.org/r/20200908095657.26821-4-mrangankar@marvell.com
Signed-off-by: Nilesh Javali 
Signed-off-by: Manish Rangankar 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: qedi: Protect active command list to avoid list corruption

2020-10-29T08:58:08+00:00

[ Upstream commit c0650e28448d606c84f76c34333dba30f61de993 ]

Protect active command list for non-I/O commands like login response,
logout response, text response, and recovery cleanup of active list to
avoid list corruption.

Link: https://lore.kernel.org/r/20200908095657.26821-5-mrangankar@marvell.com
Signed-off-by: Nilesh Javali 
Signed-off-by: Manish Rangankar 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: qedf: Return SUCCESS if stale rport is encountered

2020-10-29T08:58:07+00:00

[ Upstream commit 10aff62fab263ad7661780816551420cea956ebb ]

If SUCCESS is not returned, error handling will escalate. Return SUCCESS
similar to other conditions in this function.

Link: https://lore.kernel.org/r/20200907121443.5150-6-jhasan@marvell.com
Signed-off-by: Saurav Kashyap 
Signed-off-by: Javed Hasan 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: qla2xxx: Warn if done() or free() are called on an already freed srb

2020-10-29T08:58:07+00:00

[ Upstream commit c0014f94218ea3a312f6235febea0d626c5f2154 ]

Emit a warning when ->done or ->free are called on an already freed
srb. There is a hidden use-after-free bug in the driver which corrupts
the srb memory pool which originates from the cleanup callbacks.

An extensive search didn't bring any lights on the real problem. The
initial fix was to set both pointers to NULL and try to catch invalid
accesses. But instead the memory corruption was gone and the driver
didn't crash. Since not all calling places check for NULL pointer, add
explicitly default handlers. With this we workaround the memory
corruption and add a debug help.

Link: https://lore.kernel.org/r/20200908081516.8561-2-dwagner@suse.de
Reviewed-by: Martin Wilck 
Reviewed-by: Arun Easi 
Signed-off-by: Daniel Wagner 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: ibmvfc: Fix error return in ibmvfc_probe()

2020-10-29T08:58:07+00:00

[ Upstream commit 5e48a084f4e824e1b624d3fd7ddcf53d2ba69e53 ]

Fix to return error code PTR_ERR() from the error handling case instead of
0.

Link: https://lore.kernel.org/r/20200907083949.154251-1-jingxiangfeng@huawei.com
Acked-by: Tyrel Datwyler 
Signed-off-by: Jing Xiangfeng 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin