Re: [PATCH v2] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race
From: yangxingui
Date: Mon Jul 13 2026 - 22:16:13 EST
Hi, John
On 2026/7/13 19:26, John Garry wrote:
On 13/07/2026 04:10, yangxingui wrote:
Kindly ping for review...
On 2026/7/2 11:32, Xingui Yang wrote:
Commit fbefe22811c3140 ("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().
Fixes: fbefe22811c3140 ("scsi: libsas: Don't always drain event workqueue for HA resume")
Signed-off-by: Xingui Yang <yangxingui@xxxxxxxxxx>
Any idea why this problem has only been discovered after 5 years (from fbefe22811c3140 being merged)?
Is there some new test case?
Yes, the test environment is connected to more SATA disks. During the wake-up process, the controller wakes up first, and then the disks wake up one by one. Since the number of SATA disks has increased, and the SATA disk enter the EH (Error Handling) process when waking up, the wake-up time has become longer than before. It is possible that the controller has already entered the next suspend state, while many disks are still in the previous wake-up process, leading to a failure in disk wake-up and the disks being disabled.
However, we have tested some different kernel versions in between and found that the following patch significantly improves this issue, but it does not completely resolve it.
bede543d2f8a: ACPI: OSL: Use usleep_range() in acpi_os_sleep()
In addition, if some disks wake up a bit slowly, it may also lead to ssubsequent disk wake-up failure.
[ 286.932540] hisi_sas_v3_hw 0000:32:04.0: resuming from operating state [D0]
[ 287.732627] hisi_sas_v3_hw 0000:32:04.0: end of resuming controller
[ 293.167893] hisi_sas_v3_hw 0000:32:04.0: entering suspend state
[ 341.760789] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 341.761006] sas: Executing internal abort failed 5000000000000307 (-22)
[ 341.761021] hisi_sas_v3_hw 0000:32:04.0: I_T nexus reset: internal abort (-22)
[ 341.761028] sas: ata4: end_device-3:3: Unable to reset ata device?
[ 341.916134] sas: lldd_execute_task returned: -22
[ 341.916161] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x40)
[ 341.916165] ata4.00: revalidation failed (errno=-5)
[ 346.980523] sas: Executing internal abort failed 5000000000000307 (-22)
[ 346.980542] hisi_sas_v3_hw 0000:32:04.0: I_T nexus reset: internal abort (-22)
[ 346.980552] sas: ata4: end_device-3:3: Unable to reset ata device?
[ 347.136137] sas: lldd_execute_task returned: -22
[ 347.136163] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x40)
[ 347.136169] ata4.00: revalidation failed (errno=-5)
[ 352.356924] sas: Executing internal abort failed 5000000000000307 (-22)
[ 352.357001] hisi_sas_v3_hw 0000:32:04.0: I_T nexus reset: internal abort (-22)
[ 352.357011] sas: ata4: end_device-3:3: Unable to reset ata device?
[ 352.512174] sas: lldd_execute_task returned: -22
[ 352.512255] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x40)
[ 352.512263] ata4.00: revalidation failed (errno=-5)
[ 352.512269] ata4.00: disable device
[ 352.512324] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
[ 352.512408] sas: sas_resume_sata: for direct-attached device 5000000000000307 returned -19
Thanks,
Xingui
.