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

[yangxingui <yangxingui@huawei.com>]

Hi, John

On 2026/7/14 16:26, John Garry wrote:
> On 14/07/2026 03:15, yangxingui wrote:
>>>>> Fixes: fbefe22811c3140 ("scsi: libsas: Don't always drain event 
>>>>> workqueue for HA resume")
>>>>> Signed-off-by: Xingui Yang <yangxingui@huawei.com>
>>>
>>> Any idea why this problem has only been discovered after 5 years 
>>> (from fbefe22811c3140 being merged)?
>>>
>>> Is there some new test case?
> 
> ok, I can check below. But another question is if this applies to only 
> hisi_sas driver? I mean, you are changing libsas and the hisi_sas, but 
> not other libsas-based drivers - why? They support suspend/resume.

There are five libsas consumers (callers of sas_register_ha): hisi_sas,
isci, pm8001, aic94xx, and mvsas. Only hisi_sas needs a driver-side 
change, because it is the only driver that satisfies all three
conditions below simultaneously.

1. Only hisi_sas used sas_resume_ha_no_sync().
isci/init.c:               sas_resume_ha(&ihost->sas_ha);
pm8001/pm8001_init.c:      sas_resume_ha(sha);
hisi_sas/hisi_sas_v3_hw.c: sas_resume_ha_no_sync(sha);  ← only caller
isci and pm8001 have always used the draining variant. aic94xx and
mvsas do not register any PM ops — their pci_driver structs have no
.driver.pm field — so they never enter the resume path.

2. Only hisi_sas establishes a device_link between SCSI devices and
the HBA. Commit 16fd4a7c5917 added device_link_add() in
hisi_sas_v3_hw.c to keep the HBA active while associated SCSI devices
are active. A side effect of this device_link is that
scsi_remove_device() in the PHYE_RESUME_TIMEOUT handler waits for the
HBA to be runtime-active — the direct cause of the original deadlock.
None of the other four drivers uses device_link_add() for PM sync, so
their sas_destruct_devices() path never blocks on host resume.
Original deadlock as follow:
[ 1335.875252] Call trace:
[ 1335.878380]  __switch_to+0x150/0x238
[ 1335.882646]  __schedule+0x388/0x880
[ 1335.886825]  schedule+0x58/0x130
[ 1335.890744]  rpm_resume+0x1e4/0x940
[ 1335.894926]  __pm_runtime_resume+0x68/0x130
[ 1335.899805]  rpm_get_suppliers+0x4c/0x158
[ 1335.904506]  __rpm_callback+0x190/0x248
[ 1335.909034]  rpm_callback+0x40/0x88
[ 1335.913215]  rpm_resume+0x6a8/0x940
[ 1335.917396]  __pm_runtime_resume+0x68/0x130
[ 1335.922271]  device_release_driver_internal+0xd4/0x238
[ 1335.928104]  device_release_driver+0x20/0x38
[ 1335.933065]  bus_remove_device+0xd8/0x158
[ 1335.937768]  device_del+0x168/0x3e0
[ 1335.941944]  __scsi_remove_device+0x120/0x198
[ 1335.946988]  __scsi_remove_target+0xe8/0x1c0
[ 1335.951943]  scsi_remove_target+0x120/0x228
[ 1335.956812]  sas_rphy_remove+0x8c/0x98 [scsi_transport_sas]
[ 1335.963075]  sas_rphy_delete+0x20/0x40 [scsi_transport_sas]
[ 1335.969336]  sas_destruct_devices+0x74/0xb8 [libsas]
[ 1335.974992]  sas_deform_port+0x218/0x270 [libsas]
[ 1335.980387]  sas_phye_resume_timeout+0x2c/0x60 [libsas]
[ 1335.986303]  sas_phy_event_worker+0x38/0x68 [libsas]
[ 1335.991961]  process_one_work+0x174/0x3e0
[ 1335.996656]  worker_thread+0x22c/0x3b0
[ 1336.001091]  kthread+0xec/0x100
[ 1336.004919]  ret_from_fork+0x10/0x20

3. Only hisi_sas supports runtime PM (autosuspend). This is
consistent with your own statement in fbefe22811c3140: "Other drivers
which use libsas don't worry about this as none support runtime
suspend."

Without runtime PM, the controller never autosuspends during disk
wake-up, so the race this patch addresses cannot occur.

Thanks,
Xingui