[PATCH v3] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race

[PATCH v3] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race

[Xingui Yang]

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().

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: fbefe22811c3140 ("scsi: libsas: Don't always drain event workqueue for HA resume")
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
---
Changes since v2:
- Fix comment formatting: proper multi-line style, capitalize, add periods
  (feedback from John Garry).
- Fold _sas_resume_ha() into sas_resume_ha() since the wrapper is now
  redundant (feedback from John Garry).
- Expand commit message with analysis of why the reorder is safe for
  other libsas consumers (feedback from John Garry).
---
 drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 10 +------
 drivers/scsi/libsas/sas_init.c         | 37 +++++++++++++-------------
 include/scsi/libsas.h                  |  1 -
 3 files changed, 19 insertions(+), 29 deletions(-)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
index 213d5b5dea94..8a2500993e19 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v3_hw.c
@@ -5261,15 +5261,7 @@ static int _resume_v3_hw(struct device *device)
 		return rc;
 	}
 	phys_init_v3_hw(hisi_hba);
-
-	/*
-	 * If a directly-attached disk is removed during suspend, a deadlock
-	 * may occur, as the PHYE_RESUME_TIMEOUT processing will require the
-	 * hisi_hba->device to be active, which can only happen when resume
-	 * completes. So don't wait for the HA event workqueue to drain upon
-	 * resume.
-	 */
-	sas_resume_ha_no_sync(sha);
+	sas_resume_ha(sha);
 	clear_bit(HISI_SAS_RESETTING_BIT, &hisi_hba->flags);
 
 	dev_warn(dev, "end of resuming controller\n");
diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
index 0bec236f0fb5..c3f3d05b46de 100644
--- a/drivers/scsi/libsas/sas_init.c
+++ b/drivers/scsi/libsas/sas_init.c
@@ -410,7 +410,7 @@ static void sas_resume_insert_broadcast_ha(struct sas_ha_struct *ha)
 	}
 }
 
-static void _sas_resume_ha(struct sas_ha_struct *ha, bool drain)
+void sas_resume_ha(struct sas_ha_struct *ha)
 {
 	const unsigned long tmo = msecs_to_jiffies(25000);
 	int i;
@@ -426,6 +426,23 @@ static void _sas_resume_ha(struct sas_ha_struct *ha, bool drain)
 		dev_info(ha->dev, "waiting up to 25 seconds for %d phy%s to resume\n",
 			 i, i > 1 ? "s" : "");
 	wait_event_timeout(ha->eh_wait_q, phys_suspended(ha) == 0, tmo);
+
+	/*
+	 * All phys are back up or timed out. Turn on I/O and drain
+	 * pending work.
+	 */
+	scsi_unblock_requests(ha->shost);
+	sas_drain_work(ha);
+
+	/*
+	 * Send PHYE_RESUME_TIMEOUT after sas_drain_work(). The handler
+	 * calls sas_deform_port() -> sas_destruct_devices(), which removes
+	 * SCSI devices and, for LLDDs using device_link() PM sync, waits
+	 * for the host to be runtime-active. Sending it before the drain
+	 * would deadlock: the drain waits for the handler, the handler
+	 * waits for host resume, and host resume waits for the drain to
+	 * finish.
+	 */
 	for (i = 0; i < ha->num_phys; i++) {
 		struct asd_sas_phy *phy = ha->sas_phy[i];
 
@@ -436,12 +453,6 @@ static void _sas_resume_ha(struct sas_ha_struct *ha, bool drain)
 		}
 	}
 
-	/* all phys are back up or timed out, turn on i/o so we can
-	 * flush out disks that did not return
-	 */
-	scsi_unblock_requests(ha->shost);
-	if (drain)
-		sas_drain_work(ha);
 	clear_bit(SAS_HA_RESUMING, &ha->state);
 
 	sas_queue_deferred_work(ha);
@@ -450,20 +461,8 @@ static void _sas_resume_ha(struct sas_ha_struct *ha, bool drain)
 	 */
 	sas_resume_insert_broadcast_ha(ha);
 }
-
-void sas_resume_ha(struct sas_ha_struct *ha)
-{
-	_sas_resume_ha(ha, true);
-}
 EXPORT_SYMBOL(sas_resume_ha);
 
-/* A no-sync variant, which does not call sas_drain_ha(). */
-void sas_resume_ha_no_sync(struct sas_ha_struct *ha)
-{
-	_sas_resume_ha(ha, false);
-}
-EXPORT_SYMBOL(sas_resume_ha_no_sync);
-
 void sas_suspend_ha(struct sas_ha_struct *ha)
 {
 	int i;
diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index 163f23c92b41..36d4cb567837 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -680,7 +680,6 @@ extern int sas_register_ha(struct sas_ha_struct *);
 extern int sas_unregister_ha(struct sas_ha_struct *);
 extern void sas_prep_resume_ha(struct sas_ha_struct *sas_ha);
 extern void sas_resume_ha(struct sas_ha_struct *sas_ha);
-extern void sas_resume_ha_no_sync(struct sas_ha_struct *sas_ha);
 extern void sas_suspend_ha(struct sas_ha_struct *sas_ha);
 
 int sas_phy_reset(struct sas_phy *phy, int hard_reset);
-- 
2.43.0

Re: [PATCH v3] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race

[John Garry]

On 16/07/2026 09:11, 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().
> 
> 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: fbefe22811c3140 ("scsi: libsas: Don't always drain event workqueue for HA resume")
> Signed-off-by: Xingui Yang<yangxingui@huawei.com>

Can this possibly be tested on another SCSI HBA which uses libsas? And 
using SATA disks.

Re: [PATCH v3] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race

[yangxingui]

On 2026/7/16 19:02, John Garry wrote:
> On 16/07/2026 09:11, 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().
>>
>> 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: fbefe22811c3140 ("scsi: libsas: Don't always drain event 
>> workqueue for HA resume")
>> Signed-off-by: Xingui Yang<yangxingui@huawei.com>
> 
> Can this possibly be tested on another SCSI HBA which uses libsas? And 
> using SATA disks.

Hi John,
Unfortunately I don't have access to isci or pm8001 hardware for 
testing. ^-^

If anyone on the list has such hardware and could help verify, that 
would be much appreciated.

On our side, we don't see phy-up timeouts during resume in normal
operation. The timeout scenario only occurs when a disk fails to
re-establish its link within the 25s window. To reproduce this reliably,
we simulate it by manually removing the disk during suspend — the phy 
never comes back, times out, and the PHYE_RESUME_TIMEOUT handler removes 
the device.

With this patch applied, the timeout path works correctly: no deadlock,
no spurious I/O to the removed disk, and the controller resumes normally.

Remove the sata disk under phy0 during suspend with hisi_sas, Logs as 
follow:
[ 2014.255164] hisi_sas_v3_hw 0000:32:04.0: resuming from operating 
state [D0]
[ 2016.320559] hisi_sas_v3_hw 0000:32:04.0: neither _PS0 nor _PR0 is defined
[ 2016.328062] hisi_sas_v3_hw 0000:32:04.0: waiting up to 25 seconds for 
8 phys to resume
[ 2016.328733] hisi_sas_v3_hw 0000:32:04.0: phyup: phy1 link_rate=10(sata)
[ 2016.343960] hisi_sas_v3_hw 0000:32:04.0: phyup: phy6 link_rate=10(sata)
[ 2016.344123] hisi_sas_v3_hw 0000:32:04.0: dev[38:5] direct-attached 
phy1 found
[ 2016.351259] hisi_sas_v3_hw 0000:32:04.0: phyup: phy7 link_rate=10(sata)
[ 2016.366450] hisi_sas_v3_hw 0000:32:04.0: dev[39:5] direct-attached 
phy6 found
[ 2016.366540] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2016.374284] hisi_sas_v3_hw 0000:32:04.0: dev[40:5] direct-attached 
phy7 found
[ 2016.380955] sas: ata9: end_device-6:0: dev error handler
[ 2016.381113] sas: ata10: end_device-6:1: dev error handler
[ 2016.381122] sas: ata11: end_device-6:2: dev error handler
[ 2016.381124] sas: ata12: end_device-6:7: dev error handler
[ 2016.394114] hisi_sas_v3_hw 0000:32:04.0: phydown: phy1 phy_state=0xc0
[ 2016.401238] hisi_sas_v3_hw 0000:32:04.0: ignore flutter phy1 down
[ 2016.450253] hisi_sas_v3_hw 0000:32:04.0: phyup: phy4 link_rate=11
[ 2016.457034] hisi_sas_v3_hw 0000:32:04.0: phyup: phy3 link_rate=11
[ 2016.463810] hisi_sas_v3_hw 0000:32:04.0: phyup: phy5 link_rate=11
[ 2016.470589] hisi_sas_v3_hw 0000:32:04.0: phyup: phy2 link_rate=11
[ 2016.472496] hisi_sas_v3_hw 0000:32:04.0: dev[41:1] direct-attached 
phy4 found
[ 2016.485197] hisi_sas_v3_hw 0000:32:04.0: dev[42:1] direct-attached 
phy3 found
[ 2016.496497] hisi_sas_v3_hw 0000:32:04.0: dev[43:1] direct-attached 
phy5 found
[ 2016.508342] hisi_sas_v3_hw 0000:32:04.0: dev[44:1] direct-attached 
phy2 found
[ 2016.602597] hisi_sas_v3_hw 0000:32:04.0: phyup: phy1 link_rate=10(sata)
[ 2016.768496] ata9.00: Entering active power mode
[ 2016.790465] ata9.00: configured for UDMA/133
[ 2016.795589] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2016.805949] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2016.812484] sas: ata9: end_device-6:0: dev error handler
[ 2016.812495] sas: ata10: end_device-6:1: dev error handler
[ 2016.812642] sas: ata11: end_device-6:2: dev error handler
[ 2016.812651] sas: ata12: end_device-6:7: dev error handler
[ 2016.817882] hisi_sas_v3_hw 0000:32:04.0: phydown: phy6 phy_state=0xbe
[ 2016.825006] hisi_sas_v3_hw 0000:32:04.0: ignore flutter phy6 down
[ 2017.025190] hisi_sas_v3_hw 0000:32:04.0: phyup: phy6 link_rate=10(sata)
[ 2017.192499] ata10.00: Entering active power mode
[ 2017.199314] ata10.00: configured for UDMA/133
[ 2017.204526] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2017.214886] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2017.221567] sas: ata9: end_device-6:0: dev error handler
[ 2017.221578] sas: ata10: end_device-6:1: dev error handler
[ 2017.221581] sas: ata11: end_device-6:2: dev error handler
[ 2017.221723] sas: ata12: end_device-6:7: dev error handler
[ 2017.227881] hisi_sas_v3_hw 0000:32:04.0: phydown: phy7 phy_state=0x7e
[ 2017.235006] hisi_sas_v3_hw 0000:32:04.0: ignore flutter phy7 down
[ 2017.433352] hisi_sas_v3_hw 0000:32:04.0: phyup: phy7 link_rate=10(sata)
[ 2017.600495] ata11.00: Entering active power mode
[ 2017.606721] ata11.00: configured for UDMA/133
[ 2017.611924] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2042.212434]  phy-6:0: resume timeout
[ 2042.212508] sas: sas_form_port: phy1 belongs to port0 already(1)!
[ 2042.216704] hisi_sas_v3_hw 0000:32:04.0: end of resuming controller
[ 2042.223481] sas: sas_form_port: phy6 belongs to port1 already(1)!
[ 2042.223484] sas: sas_form_port: phy7 belongs to port2 already(1)!
[ 2042.230436] hisi_sas_v3_hw 0000:32:04.0: FLR prepare
[ 2042.237860] sd 6:0:7:0: [sdj] Starting disk
[ 2046.460557] hisi_sas_v3_hw 0000:32:04.0: neither _PS0 nor _PR0 is defined
[ 2046.468806] hisi_sas_v3_hw 0000:32:04.0: phyup: phy1 link_rate=10(sata)
[ 2046.476114] hisi_sas_v3_hw 0000:32:04.0: phyup: phy6 link_rate=10(sata)
[ 2046.483413] hisi_sas_v3_hw 0000:32:04.0: phyup: phy7 link_rate=10(sata)
[ 2046.577033] hisi_sas_v3_hw 0000:32:04.0: phyup: phy3 link_rate=11
[ 2046.589979] hisi_sas_v3_hw 0000:32:04.0: phyup: phy4 link_rate=11
[ 2046.596766] hisi_sas_v3_hw 0000:32:04.0: phyup: phy5 link_rate=11
[ 2046.603548] hisi_sas_v3_hw 0000:32:04.0: phyup: phy2 link_rate=11
[ 2046.644064] hisi_sas_v3_hw 0000:32:04.0: FLR done
[ 2046.644205] sd 6:0:7:0: [sdj] Start/Stop Unit failed: Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2046.659804] sd 6:0:7:0: [sdj] Start/Stop Unit failed: Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2046.670154] sd 6:0:7:0: [sdj] Start/Stop Unit failed: Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2046.680495] sd 6:0:7:0: [sdj] Start/Stop Unit failed: Result: 
hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[ 2046.727158] sas: sas_form_port: phy1 belongs to port0 already(1)!
[ 2046.733945] sas: sas_form_port: phy6 belongs to port1 already(1)!
[ 2046.740725] sas: sas_form_port: phy7 belongs to port2 already(1)!
[ 2046.747504] sas: sas_form_port: phy3 belongs to port3 already(1)!
[ 2046.754284] sas: sas_form_port: phy4 belongs to port5 already(1)!
[ 2046.761064] sas: sas_form_port: phy5 belongs to port4 already(1)!
[ 2046.767845] sas: sas_form_port: phy2 belongs to port6 already(1)!
[ 2047.420415] hisi_sas_v3_hw 0000:32:04.0: entering suspend state
[ 2048.327932] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2048.334616] sas: ata9: end_device-6:0: dev error handler
[ 2048.334624] ata9.00: Entering standby power mode
[ 2048.334724] sas: ata10: end_device-6:1: dev error handler
[ 2048.334878] sas: ata11: end_device-6:2: dev error handler
[ 2048.339936] sas: lldd_execute_task returned: -22
[ 2048.339941] ata9.00: STANDBY IMMEDIATE failed (err_mask=0x40)
[ 2048.346528] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2048.356740] hisi_sas_v3_hw 0000:32:04.0: dev[38:5] direct-attached 
phy1 is gone
[ 2048.364898] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2048.371587] sas: ata9: end_device-6:0: dev error handler
[ 2048.371598] sas: ata10: end_device-6:1: dev error handler
[ 2048.371602] ata10.00: Entering standby power mode
[ 2048.371742] sas: ata11: end_device-6:2: dev error handler
[ 2048.377001] sas: lldd_execute_task returned: -22
[ 2048.377007] ata10.00: STANDBY IMMEDIATE failed (err_mask=0x40)
[ 2048.383679] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2048.393891] hisi_sas_v3_hw 0000:32:04.0: dev[39:5] direct-attached 
phy6 is gone
[ 2048.402048] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
[ 2048.408738] sas: ata9: end_device-6:0: dev error handler
[ 2048.408748] sas: ata10: end_device-6:1: dev error handler
[ 2048.408751] sas: ata11: end_device-6:2: dev error handler
[ 2048.408756] ata11.00: Entering standby power mode
[ 2048.414150] sas: lldd_execute_task returned: -22
[ 2048.414157] ata11.00: STANDBY IMMEDIATE failed (err_mask=0x40)
[ 2048.420828] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 
tries: 1
[ 2048.430891] hisi_sas_v3_hw 0000:32:04.0: dev[40:5] direct-attached 
phy7 is gone
[ 2048.438893] hisi_sas_v3_hw 0000:32:04.0: dev[42:1] direct-attached 
phy3 is gone
[ 2048.446893] hisi_sas_v3_hw 0000:32:04.0: dev[43:1] direct-attached 
phy5 is gone
[ 2048.454891] hisi_sas_v3_hw 0000:32:04.0: dev[41:1] direct-attached 
phy4 is gone
[ 2048.462885] hisi_sas_v3_hw 0000:32:04.0: dev[44:1] direct-attached 
phy2 is gone
[ 2048.470956] hisi_sas_v3_hw 0000:32:04.0: end of suspending controller

Thanks,
Xingui
.

Re: [PATCH v3] scsi: libsas: fix HA resume deadlock and hisi_sas disk-wake race

[John Garry]

On 16/07/2026 12:48, yangxingui wrote:

+

>>> Fixes: fbefe22811c3140 ("scsi: libsas: Don't always drain event 
>>> workqueue for HA resume")
>>> Signed-off-by: Xingui Yang<yangxingui@huawei.com>
>>
>> Can this possibly be tested on another SCSI HBA which uses libsas? And 
>> using SATA disks.
> 
> Hi John,
> Unfortunately I don't have access to isci or pm8001 hardware for 
> testing. ^-^
> 
> If anyone on the list has such hardware and could help verify, that 
> would be much appreciated.

By checking the mailing lists you can see who has been hacking libsas or 
drivers which use libsas in future.

For now:

Reviewed-by: John Garry <john.g.garry@oracle.com>