linux-stable.git/include/scsi, branch v6.1.185

scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race

2026-08-19T15:16:13+00:00

[ Upstream commit 3dbbbf656b850c9c8de05df6ad4a1dfc6ff02845 ]

Commit fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue
for HA resume") introduced sas_resume_ha_no_sync() to avoid a deadlock:
the PHYE_RESUME_TIMEOUT handler, running on the HA event workqueue,
calls sas_deform_port() -> sas_destruct_devices(), which removes SCSI
devices and waits for the host to become runtime-active. But the host
cannot resume until sas_resume_ha() -> sas_drain_work() returns, and the
drain is blocked on that very handler.

However skipping the drain reintroduces a race: hisi_sas returns from
resume before all PHY UP work and libsas discovery work finish. The
controller may then autosuspend while disks are still waking up. The
disks issue IO to a suspended controller, the IO fails, and the disks
get disabled.

Fix the deadlock at its source by moving the PHYE_RESUME_TIMEOUT
notification to after sas_drain_work(). By then the host resume is about
to complete, so device removal through device_link no longer blocks on
the resume and the cycle is broken.

With the deadlock gone, restore sas_resume_ha() (the draining variant)
in hisi_sas and remove sas_resume_ha_no_sync().

The reorder is safe for the other libsas consumers (isci, pm8001,
aic94xx, mvsas). During suspend, sas_suspend_devices() calls
sas_notify_lldd_dev_gone() for each device, which sets dev->lldd_dev to
NULL. When scsi_unblock_requests re-enables I/O in resume, any I/O to a
timed-out phy's disk is immediately rejected by the LLDD before reaching
hardware: isci returns SAS_DEVICE_UNKNOWN (mapped to DID_BAD_TARGET),
and pm8001 returns SAS_PHY_DOWN (mapped to DID_NO_CONNECT). Both
complete directly via scsi_done() without entering SCSI EH. This is
identical in both the old and new ordering since lldd_dev_gone runs
during suspend, before resume. The reorder only affects when the
PHYE_RESUME_TIMEOUT handler runs (synchronized by sas_drain_work()
vs. asynchronous after resume returns), not whether I/O can reach the
device. aic94xx and mvsas do not register any PM ops and never reach
this code path.

Fixes: fbefe22811c3 ("scsi: libsas: Don't always drain event workqueue for HA resume")
Signed-off-by: Xingui Yang 
Reviewed-by: John Garry 
Link: https://patch.msgid.link/20260716081145.3950172-1-yangxingui@huawei.com
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

scsi: libsas: Delete struct scsi_core

2026-08-19T15:16:13+00:00

[ Upstream commit 1136a0225d0582c4464fa37e3a91ed4b19b8745e ]

Since commit 79855d178557 ("libsas: remove task_collector mode"), struct
scsi_core only contains a reference to the shost. struct scsi_core is only
used in sas_ha_struct.core, so delete scsi_core and replace with a
reference to the shost there.

Signed-off-by: John Garry 
Link: https://lore.kernel.org/r/20230815115156.343535-5-john.g.garry@oracle.com
Reviewed-by: Jason Yan 
Reviewed-by: Damien Le Moal 
Signed-off-by: Martin K. Petersen 
Stable-dep-of: 3dbbbf656b85 ("scsi: libsas: Fix HA resume deadlock and hisi_sas disk-wake race")
Signed-off-by: Sasha Levin

scsi: core: Fix error handler encryption support

2026-02-06T15:43:57+00:00

commit 9a49157deeb23581fc5c8189b486340d7343264a upstream.

Some low-level drivers (LLD) access block layer crypto fields, such as
rq->crypt_keyslot and rq->crypt_ctx within `struct request`, to
configure hardware for inline encryption.  However, SCSI Error Handling
(EH) commands (e.g., TEST UNIT READY, START STOP UNIT) should not
involve any encryption setup.

To prevent drivers from erroneously applying crypto settings during EH,
this patch saves the original values of rq->crypt_keyslot and
rq->crypt_ctx before an EH command is prepared via scsi_eh_prep_cmnd().
These fields in the 'struct request' are then set to NULL.  The original
values are restored in scsi_eh_restore_cmnd() after the EH command
completes.

This ensures that the block layer crypto context does not leak into EH
command execution.

Signed-off-by: Brian Kao 
Link: https://patch.msgid.link/20251218031726.2642834-1-powenkao@google.com
Cc: stable@vger.kernel.org
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: libsas: Add sas_task_find_rq()

2025-10-19T14:23:07+00:00

[ Upstream commit a9ee3f840646e2ec419c734e592ffe997195435e ]

blk-mq already provides a unique tag per request. Some libsas LLDDs - like
hisi_sas - already use this tag as the unique per-I/O HW tag.

Add a common function to provide the request associated with a sas_task for
all libsas LLDDs.

Signed-off-by: John Garry 
Link: https://lore.kernel.org/r/1666091763-11023-2-git-send-email-john.garry@huawei.com
Reviewed-by: Jack Wang 
Reviewed-by: Jason Yan 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Martin K. Petersen 
Stable-dep-of: 60cd16a3b743 ("scsi: mvsas: Fix use-after-free bugs in mvs_work_queue")
Signed-off-by: Sasha Levin

scsi: core: Fix the return value of scsi_logical_block_count()

2024-08-29T15:30:49+00:00

commit f03e94f23b04c2b71c0044c1534921b3975ef10c upstream.

scsi_logical_block_count() should return the block count of a given SCSI
command. The original implementation ended up shifting twice, leading to an
incorrect count being returned. Fix the conversion between bytes and
logical blocks.

Cc: stable@vger.kernel.org
Fixes: 6a20e21ae1e2 ("scsi: core: Add helper to return number of logical blocks in a request")
Signed-off-by: Chaotian Jing 
Link: https://lore.kernel.org/r/20240813053534.7720-1-chaotian.jing@mediatek.com
Reviewed-by: Bart Van Assche 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: mpi3mr: Fix ATA NCQ priority support

2024-06-21T12:35:44+00:00

commit 90e6f08915ec6efe46570420412a65050ec826b2 upstream.

The function mpi3mr_qcmd() of the mpi3mr driver is able to indicate to
the HBA if a read or write command directed at an ATA device should be
translated to an NCQ read/write command with the high prioiryt bit set
when the request uses the RT priority class and the user has enabled NCQ
priority through sysfs.

However, unlike the mpt3sas driver, the mpi3mr driver does not define
the sas_ncq_prio_supported and sas_ncq_prio_enable sysfs attributes, so
the ncq_prio_enable field of struct mpi3mr_sdev_priv_data is never
actually set and NCQ Priority cannot ever be used.

Fix this by defining these missing atributes to allow a user to check if
an ATA device supports NCQ priority and to enable/disable the use of NCQ
priority. To do this, lift the function scsih_ncq_prio_supp() out of the
mpt3sas driver and make it the generic SCSI SAS transport function
sas_ata_ncq_prio_supported(). Nothing in that function is hardware
specific, so this function can be used in both the mpt3sas driver and
the mpi3mr driver.

Reported-by: Scott McCoy 
Fixes: 023ab2a9b4ed ("scsi: mpi3mr: Add support for queue command processing")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal 
Link: https://lore.kernel.org/r/20240611083435.92961-1-dlemoal@kernel.org
Reviewed-by: Niklas Cassel 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

scsi: sd: usb_storage: uas: Access media prior to querying device properties

2024-04-13T11:05:24+00:00

[ Upstream commit 321da3dc1f3c92a12e3c5da934090d2992a8814c ]

It has been observed that some USB/UAS devices return generic properties
hardcoded in firmware for mode pages for a period of time after a device
has been discovered. The reported properties are either garbage or they do
not accurately reflect the characteristics of the physical storage device
attached in the case of a bridge.

Prior to commit 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to
avoid calling revalidate twice") we would call revalidate several
times during device discovery. As a result, incorrect values would
eventually get replaced with ones accurately describing the attached
storage. When we did away with the redundant revalidate pass, several
cases were reported where devices reported nonsensical values or would
end up in write-protected state.

An initial attempt at addressing this issue involved introducing a
delayed second revalidate invocation. However, this approach still
left some devices reporting incorrect characteristics.

Tasos Sahanidis debugged the problem further and identified that
introducing a READ operation prior to MODE SENSE fixed the problem and that
it wasn't a timing issue. Issuing a READ appears to cause the devices to
update their state to reflect the actual properties of the storage
media. Device properties like vendor, model, and storage capacity appear to
be correctly reported from the get-go. It is unclear why these devices
defer populating the remaining characteristics.

Match the behavior of a well known commercial operating system and
trigger a READ operation prior to querying device characteristics to
force the device to populate the mode pages.

The additional READ is triggered by a flag set in the USB storage and
UAS drivers. We avoid issuing the READ for other transport classes
since some storage devices identify Linux through our particular
discovery command sequence.

Link: https://lore.kernel.org/r/20240213143306.2194237-1-martin.petersen@oracle.com
Fixes: 1e029397d12f ("scsi: sd: Reorganize DIF/DIX code to avoid calling revalidate twice")
Cc: stable@vger.kernel.org
Reported-by: Tasos Sahanidis 
Reviewed-by: Ewan D. Milne 
Reviewed-by: Bart Van Assche 
Tested-by: Tasos Sahanidis 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Revert "scsi: core: Add struct for args to execution functions"

2024-04-13T11:05:24+00:00

This reverts commit cf33e6ca12d814e1be2263cb76960d0019d7fb94 which is
commit d0949565811f0896c1c7e781ab2ad99d34273fdf upstream.

It is known to cause problems and has asked to be dropped.

Link: https://lore.kernel.org/r/yq1frvvpymp.fsf@ca-mkp.ca.oracle.com
Cc: Tasos Sahanidis 
Cc: Ewan D. Milne 
Cc: Bart Van Assche 
Cc: Tasos Sahanidis 
Cc: Martin K. Petersen 
Cc: James Bottomley 
Cc: Sasha Levin 
Reported-by: John David Anglin 
Reported-by: Cyril Brulebois 
Signed-off-by: Greg Kroah-Hartman

Revert "scsi: sd: usb_storage: uas: Access media prior to querying device properties"

2024-04-13T11:05:23+00:00

This reverts commit b73dd5f9997279715cd450ee8ca599aaff2eabb9 which is
commit 321da3dc1f3c92a12e3c5da934090d2992a8814c upstream.

It is known to cause problems and has asked to be dropped.

Link: https://lore.kernel.org/r/yq1frvvpymp.fsf@ca-mkp.ca.oracle.com
Cc: Tasos Sahanidis 
Cc: Ewan D. Milne 
Cc: Bart Van Assche 
Cc: Tasos Sahanidis 
Cc: Martin K. Petersen 
Cc: James Bottomley 
Cc: Sasha Levin 
Reported-by: John David Anglin 
Reported-by: Cyril Brulebois 
Signed-off-by: Greg Kroah-Hartman

scsi: sd: Fix TCG OPAL unlock on system resume

2024-04-03T13:19:51+00:00

commit 0c76106cb97548810214def8ee22700bbbb90543 upstream.

Commit 3cc2ffe5c16d ("scsi: sd: Differentiate system and runtime start/stop
management") introduced the manage_system_start_stop scsi_device flag to
allow libata to indicate to the SCSI disk driver that nothing should be
done when resuming a disk on system resume. This change turned the
execution of sd_resume() into a no-op for ATA devices on system
resume. While this solved deadlock issues during device resume, this change
also wrongly removed the execution of opal_unlock_from_suspend().  As a
result, devices with TCG OPAL locking enabled remain locked and
inaccessible after a system resume from sleep.

To fix this issue, introduce the SCSI driver resume method and implement it
with the sd_resume() function calling opal_unlock_from_suspend(). The
former sd_resume() function is renamed to sd_resume_common() and modified
to call the new sd_resume() function. For non-ATA devices, this result in
no functional changes.

In order for libata to explicitly execute sd_resume() when a device is
resumed during system restart, the function scsi_resume_device() is
introduced. libata calls this function from the revalidation work executed
on devie resume, a state that is indicated with the new device flag
ATA_DFLAG_RESUMING. Doing so, locked TCG OPAL enabled devices are unlocked
on resume, allowing normal operation.

Fixes: 3cc2ffe5c16d ("scsi: sd: Differentiate system and runtime start/stop management")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218538
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal 
Link: https://lore.kernel.org/r/20240319071209.1179257-1-dlemoal@kernel.org
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman