kernel/linux.git/drivers/scsi, branch linux-5.9.y

scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()"

2020-12-16T09:58:37+00:00

commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream. My patch caused kernel Oopses and delays in boot. Revert it. The problem was that I moved the "mem->dma = paddr;" before the call to be_fill_queue(). But the first thing that the be_fill_queue() function does is memset the whole struct to zero which overwrites the assignment. Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()") Cc: stable Reported-by: Thomas Lamprecht Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE

2020-12-16T09:58:31+00:00

[ Upstream commit 73cc291c270248567245f084dcdf5078069af6b5 ] If someone plays with the UFS clk scaling devfreq governor through sysfs, ufshcd_devfreq_scale may be called even when HBA is not runtime ACTIVE. This can lead to unexpected error. We cannot just protect it by calling pm_runtime_get_sync() because that may cause a race condition since HBA runtime suspend ops need to suspend clk scaling. To fix this call pm_runtime_get_noresume() and check HBA's runtime status. Only proceed if HBA is runtime ACTIVE, otherwise just bail. governor_store devfreq_performance_handler update_devfreq devfreq_set_target ufshcd_devfreq_target ufshcd_devfreq_scale Link: https://lore.kernel.org/r/1600758548-28576-1-git-send-email-cang@codeaurora.org Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: Fix unexpected values from ufshcd_read_desc_param()

2020-12-16T09:58:31+00:00

[ Upstream commit 1699f980d87fb678a669490462cf0b9517c1fb47 ] WB-related sysfs entries can be accessed even when an UFS device does not support the feature. The descriptors which are not supported by the UFS device may be wrongly reported when they are accessed from their corrsponding sysfs entries. Fix it by adding a sanity check of parameter offset against the actual decriptor length. Link: https://lore.kernel.org/r/1603346348-14149-1-git-send-email-cang@codeaurora.org Reviewed-by: Asutosh Das Acked-by: Daejun Park Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: storvsc: Fix error return in storvsc_probe()

2020-12-16T09:58:28+00:00

[ Upstream commit 6112ff4e8f393e7e297dff04eff0987f94d37fa1 ] Return -ENOMEM from the error handling case instead of 0. Link: https://lore.kernel.org/r/20201127030206.104616-1-jingxiangfeng@huawei.com Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun") Reviewed-by: Michael Kelley Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: mpt3sas: Fix ioctl timeout

2020-12-11T12:22:09+00:00

commit 42f687038bcc34aa919e0e4c29b04e4cda3f6a79 upstream. Commit c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") modified the ioctl path 'timeout' variable type to u8 from unsigned long, limiting the maximum timeout value that the driver can support to 255 seconds. If the management application is requesting a higher value the resulting timeout will be zero. The operation times out immediately and the ioctl request fails. Change datatype back to unsigned long. Link: https://lore.kernel.org/r/20201125094838.4340-1-suganath-prabu.subramani@broadcom.com Fixes: c1a6c5ac4278 ("scsi: mpt3sas: For NVME device, issue a protocol level reset") Cc: #v4.18+ Signed-off-by: Suganath Prabu S Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman

scsi: ufs: Fix race between shutdown and runtime resume flow

2020-12-02T07:51:54+00:00

[ Upstream commit e92643db514803c2c87d72caf5950b4c0a8faf4a ] If UFS host device is in runtime-suspended state while UFS shutdown callback is invoked, UFS device shall be resumed for register accesses. Currently only UFS local runtime resume function will be invoked to wake up the host. This is not enough because if someone triggers runtime resume from block layer, then race may happen between shutdown and runtime resume flow, and finally lead to unlocked register access. To fix this, in ufshcd_shutdown(), use pm_runtime_get_sync() instead of resuming UFS device by ufshcd_runtime_resume() "internally" to let runtime PM framework manage the whole resume flow. Link: https://lore.kernel.org/r/20201119062916.12931-1-stanley.chu@mediatek.com Fixes: 57d104c153d3 ("ufs: add UFS power management support") Reviewed-by: Can Guo Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: libiscsi: Fix NOP race condition

2020-12-02T07:51:51+00:00

[ Upstream commit fe0a8a95e7134d0b44cd407bc0085b9ba8d8fe31 ] iSCSI NOPs are sometimes "lost", mistakenly sent to the user-land iscsid daemon instead of handled in the kernel, as they should be, resulting in a message from the daemon like: iscsid: Got nop in, but kernel supports nop handling. This can occur because of the new forward- and back-locks, and the fact that an iSCSI NOP response can occur before processing of the NOP send is complete. This can result in "conn->ping_task" being NULL in iscsi_nop_out_rsp(), when the pointer is actually in the process of being set. To work around this, we add a new state to the "ping_task" pointer. In addition to NULL (not assigned) and a pointer (assigned), we add the state "being set", which is signaled with an INVALID pointer (using "-1"). Link: https://lore.kernel.org/r/20201106193317.16993-1-leeman.duncan@gmail.com Reviewed-by: Mike Christie Signed-off-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: Try to save power mode change and UIC cmd completion timeout

2020-11-24T12:38:52+00:00

[ Upstream commit 0f52fcb99ea2738a0a0f28e12cf4dd427069dd2a ] Use the uic_cmd->cmd_active as a flag to track the lifecycle of an UIC cmd. The flag is set before sending the UIC cmd and cleared in IRQ handler. When a PMC or UIC cmd completion timeout happens, if the flag is not set, instead of returning timeout error, we still treat it as a successful operation. This is to deal with the scenario in which completion has been raised but the one waiting for the completion cannot be awaken in time due to kernel scheduling problem. Link: https://lore.kernel.org/r/1604384682-15837-3-git-send-email-cang@codeaurora.org Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

2020-11-24T12:38:52+00:00

[ Upstream commit da3fecb0040324c08f1587e5bff1f15f36be1872 ] The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be decreased back in ufshcd_ungate_work() in a paired way. However, if specific ufshcd_hold/release sequences are met, it is possible that scsi_block_reqs_cnt is increased twice but only one ungate work is queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and ufshcd_ungate_work() in a paired way, increase it only if queue_work() returns true. Link: https://lore.kernel.org/r/1604384682-15837-2-git-send-email-cang@codeaurora.org Reviewed-by: Hongwu Su Reviewed-by: Stanley Chu Reviewed-by: Bean Huo Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: mpt3sas: Fix timeouts observed while reenabling IRQ

2020-11-18T18:22:12+00:00

[ Upstream commit 5feed64f9199ff90c4239971733f23f30aeb2484 ] While reenabling the IRQ after irq poll there may be small time window where HBA firmware has posted some replies and raise the interrupts but driver has not received the interrupts. So we may observe I/O timeouts as the driver has not processed the replies as interrupts got missed while reenabling the IRQ. To fix this issue the driver has to go for one more round of processing the reply descriptors from reply descriptor post queue after enabling the IRQ. Link: https://lore.kernel.org/r/20201102072746.27410-1-sreekanth.reddy@broadcom.com Reported-by: Tomas Henzl Reviewed-by: Tomas Henzl Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin