linux-stable.git/drivers/scsi, branch v6.14.2

scsi: hisi_sas: Fixed failure to issue vendor specific commands

2025-04-10T12:44:09+00:00

[ Upstream commit 750d4fbe2c20e65d764c70afe2c9e6cfa874b044 ]

At present, we determine the protocol through the cmd type, but other cmd
types, such as vendor-specific commands, default to the PIO protocol.  This
strategy often causes the execution of different vendor-specific commands
to fail. In fact, for these commands, a better way is to use the protocol
configured by the command's tf to determine its protocol.

Fixes: 6f2ff1a1311e ("hisi_sas: add v2 path to send ATA command")
Signed-off-by: Xingui Yang 
Link: https://lore.kernel.org/r/20250220090011.313848-1-liyihang9@huawei.com
Reviewed-by: Yihang Li 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: mpt3sas: Fix a locking bug in an error path

2025-04-10T12:44:03+00:00

[ Upstream commit 38afcf0660f5c408ba6c2f0ba3a9729e0102fe2e ]

Call mutex_unlock(&ioc->hostdiag_unlock_mutex) once from error paths
instead of twice.

This patch fixes the following Clang -Wthread-safety errors:

drivers/scsi/mpt3sas/mpt3sas_base.c:8085:2: error: mutex 'ioc->hostdiag_unlock_mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis]
 8085 |         pci_cfg_access_unlock(ioc->pdev);
      |         ^
drivers/scsi/mpt3sas/mpt3sas_base.c:8019:2: note: mutex acquired here
 8019 |         mutex_lock(&ioc->hostdiag_unlock_mutex);
      |         ^
./include/linux/mutex.h:171:26: note: expanded from macro 'mutex_lock'
  171 | #define mutex_lock(lock) mutex_lock_nested(lock, 0)
      |                          ^
drivers/scsi/mpt3sas/mpt3sas_base.c:8085:2: error: mutex 'ioc->hostdiag_unlock_mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis]
 8085 |         pci_cfg_access_unlock(ioc->pdev);
      |         ^
drivers/scsi/mpt3sas/mpt3sas_base.c:8019:2: note: mutex acquired here
 8019 |         mutex_lock(&ioc->hostdiag_unlock_mutex);
      |         ^
./include/linux/mutex.h:171:26: note: expanded from macro 'mutex_lock'
  171 | #define mutex_lock(lock) mutex_lock_nested(lock, 0)
      |                          ^
drivers/scsi/mpt3sas/mpt3sas_base.c:8087:2: error: releasing mutex 'ioc->hostdiag_unlock_mutex' that was not held [-Werror,-Wthread-safety-analysis]
 8087 |         mutex_unlock(&ioc->hostdiag_unlock_mutex);
      |         ^

Cc: Ranjan Kumar 
Fixes: c0767560b012 ("scsi: mpt3sas: Reload SBR without rebooting HBA")
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20250210203936.2946494-3-bvanassche@acm.org
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: mpi3mr: Fix locking in an error path

2025-04-10T12:44:03+00:00

[ Upstream commit c733741ae1c3a5927f72664b0d760d5f4c14f96b ]

Make all error paths unlock rioc->bsg_cmds.mutex.

This patch fixes the following Clang -Wthread-safety errors:

drivers/scsi/mpi3mr/mpi3mr_app.c:2835:1: error: mutex 'mrioc->bsg_cmds.mutex' is not held on every path through here [-Werror,-Wthread-safety-analysis]
 2835 | }
      | ^
drivers/scsi/mpi3mr/mpi3mr_app.c:2332:6: note: mutex acquired here
 2332 |         if (mutex_lock_interruptible(&mrioc->bsg_cmds.mutex))
      |             ^
./include/linux/mutex.h:172:40: note: expanded from macro 'mutex_lock_interruptible'
  172 | #define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 0)
      |                                        ^

Cc: Sathya Prakash 
Fixes: fb231d7deffb ("scsi: mpi3mr: Support for preallocation of SGL BSG data buffers part-2")
Signed-off-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20250210203936.2946494-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: mpt3sas: Reduce log level of ignore_delay_remove message to KERN_INFO

2025-04-10T12:44:02+00:00

[ Upstream commit fb27da6e06a0869d2e36255bb7e0b6102daf712f ]

On several systems with Dell HBA controller Linux prints the warning below:

    $ dmesg | grep -e "Linux version" -e "DMI: Dell"  -e "ignore_delay_remove"
    [    0.000000] Linux version 6.12.11.mx64.479 (root@lucy.molgen.mpg.de) (gcc (GCC) 12.3.0, GNU ld (GNU Binutils) 2.41) #1 SMP PREEMPT_DYNAMIC Fri Jan 24 13:30:47 CET 2025
    [    0.000000] DMI: Dell Inc. PowerEdge R7625/0M7YXP, BIOS 1.10.6 12/06/2024
    [    9.386551] scsi 0:0:4:0: set ignore_delay_remove for handle(0x0012)

A user does not know, what to do about it, and everything seems to work as
expected. Therefore, remove the log level from warning to info.

Device information:

    $ dmesg | grep -e 0:4:0 -e '12)'
    [    8.857606] mpt3sas_cm0: config page(0x00000000db0e4179) - dma(0xfd5f6000): size(512)
    [    9.133856] scsi 0:0:0:0: SATA: handle(0x0017), sas_addr(0x3c0470e0d40cc20c), phy(12), device_name(0x5000039db8d2284b)
    [    9.366341] mpt3sas_cm0: handle(0x12) sas_address(0x3c0570e0d40cc208) port_type(0x0)
    [    9.378867] scsi 0:0:4:0: Enclosure         DP       BP_PSV           7.10 PQ: 0 ANSI: 7
    [    9.386551] scsi 0:0:4:0: set ignore_delay_remove for handle(0x0012)
    [    9.387465] scsi 0:0:4:0: SES: handle(0x0012), sas_addr(0x3c0570e0d40cc208), phy(17), device_name(0x3c0570e0d40cc208)
    [    9.387465] scsi 0:0:4:0: enclosure logical id (0x3c0470e0d4092108), slot(8)
    [    9.387465] scsi 0:0:4:0: enclosure level(0x0001), connector name( C0  )
    [    9.390495] scsi 0:0:4:0: qdepth(1), tagged(0), scsi_level(8), cmd_que(0)
    [    9.401700]  end_device-0:4: add: handle(0x0012), sas_addr(0x3c0570e0d40cc208)
    [    9.471916] ses 0:0:4:0: Attached Enclosure device
    [    9.480088] ses 0:0:4:0: Attached scsi generic sg4 type 13
    $ lspci -nn -k -s 41:
    41:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI Fusion-MPT 12GSAS/PCIe Secure SAS38xx [1000:00e6]
    	DeviceName: SL3 NonRAID
    	Subsystem: Dell HBA355i Front [1028:200c]
    	Kernel driver in use: mpt3sas

Fixes: 30158dc9bbc9 ("mpt3sas: Never block the Enclosure device")
Cc: Tomas Henzl 
Signed-off-by: Paul Menzel 
Link: https://lore.kernel.org/r/20250131171640.30721-1-pmenzel@molgen.mpg.de
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: core: Clear driver private data when retrying request

2025-02-21T02:20:58+00:00

After commit 1bad6c4a57ef ("scsi: zero per-cmd private driver data for each
MQ I/O"), the xen-scsifront/virtio_scsi/snic drivers all removed code that
explicitly zeroed driver-private command data.

In combination with commit 464a00c9e0ad ("scsi: core: Kill DRIVER_SENSE"),
after virtio_scsi performs a capacity expansion, the first request will
return a unit attention to indicate that the capacity has changed. And then
the original command is retried. As driver-private command data was not
cleared, the request would return UA again and eventually time out and fail.

Zero driver-private command data when a request is retried.

Fixes: f7de50da1479 ("scsi: xen-scsifront: Remove code that zeroes driver-private command data")
Fixes: c2bb87318baa ("scsi: virtio_scsi: Remove code that zeroes driver-private command data")
Fixes: c3006a926468 ("scsi: snic: Remove code that zeroes driver-private command data")
Signed-off-by: Ye Bin 
Reviewed-by: Bart Van Assche 
Link: https://lore.kernel.org/r/20250217021628.2929248-1-yebin@huaweicloud.com
Signed-off-by: Martin K. Petersen

scsi: qla1280: Fix kernel oops when debug level > 2

2025-02-03T22:54:56+00:00

A null dereference or oops exception will eventually occur when qla1280.c
driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2.  I
think its clear from the code that the intention here is sg_dma_len(s) not
length of sg_next(s) when printing the debug info.

Signed-off-by: Magnus Lindholm 
Link: https://lore.kernel.org/r/20250125095033.26188-1-linmag7@gmail.com
Signed-off-by: Martin K. Petersen

scsi: storvsc: Set correct data length for sending SCSI command without payload

2025-02-03T22:28:07+00:00

In StorVSC, payload->range.len is used to indicate if this SCSI command
carries payload. This data is allocated as part of the private driver data
by the upper layer and may get passed to lower driver uninitialized.

For example, the SCSI error handling mid layer may send TEST_UNIT_READY or
REQUEST_SENSE while reusing the buffer from a failed command. The private
data section may have stale data from the previous command.

If the SCSI command doesn't carry payload, the driver may use this value as
is for communicating with host, resulting in possible corruption.

Fix this by always initializing this value.

Fixes: be0cf6ca301c ("scsi: storvsc: Set the tablesize based on the information given by the host")
Cc: stable@kernel.org
Tested-by: Roman Kisel 
Reviewed-by: Roman Kisel 
Reviewed-by: Michael Kelley 
Signed-off-by: Long Li 
Link: https://lore.kernel.org/r/1737601642-7759-1-git-send-email-longli@linuxonhyperv.com
Signed-off-by: Martin K. Petersen

scsi: core: Do not retry I/Os during depopulation

2025-02-03T22:10:15+00:00

Fail I/Os instead of retry to prevent user space processes from being
blocked on the I/O completion for several minutes.

Retrying I/Os during "depopulation in progress" or "depopulation restore in
progress" results in a continuous retry loop until the depopulation
completes or until the I/O retry loop is aborted due to a timeout by the
scsi_cmd_runtime_exceeced().

Depopulation is slow and can take 24+ hours to complete on 20+ TB HDDs.
Most I/Os in the depopulation retry loop end up taking several minutes
before returning the failure to user space.

Cc: stable@vger.kernel.org # 4.18.x: 2bbeb8d scsi: core: Handle depopulation and restoration in progress
Cc: stable@vger.kernel.org # 4.18.x
Fixes: e37c7d9a0341 ("scsi: core: sanitize++ in progress")
Signed-off-by: Igor Pylypiv 
Link: https://lore.kernel.org/r/20250131184408.859579-1-ipylypiv@google.com
Signed-off-by: Martin K. Petersen

scsi: core: Use GFP_NOIO to avoid circular locking dependency

2025-02-03T22:08:13+00:00

Filesystems can write to disk from page reclaim with __GFP_FS
set. Marc found a case where scsi_realloc_sdev_budget_map() ends up in
page reclaim with GFP_KERNEL, where it could try to take filesystem
locks again, leading to a deadlock.

WARNING: possible circular locking dependency detected
6.13.0 #1 Not tainted
------------------------------------------------------
kswapd0/70 is trying to acquire lock:
ffff8881025d5d78 (&q->q_usage_counter(io)){++++}-{0:0}, at: blk_mq_submit_bio+0x461/0x6e0

but task is already holding lock:
ffffffff81ef5f40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x9f/0x760

The full lockdep splat can be found in Marc's report:

https://lkml.org/lkml/2025/1/24/1101

Avoid the potential deadlock by doing the allocation with GFP_NOIO, which
prevents both filesystem and block layer recursion.

Reported-by: Marc Aurèle La France 
Signed-off-by: Rik van Riel 
Link: https://lore.kernel.org/r/20250129104525.0ae8421e@fangorn
Reviewed-by: Christoph Hellwig 
Signed-off-by: Martin K. Petersen

Merge branch '6.14/scsi-queue' into 6.14/scsi-fixes

2025-02-03T21:28:51+00:00

Pull outstanding fixes bound for this release into 6.14/scsi-fixes.

Signed-off-by: Martin K. Petersen