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

From: yangxingui

Date: Thu Jul 16 2026 - 02:46:49 EST


Hi, John

On 2026/7/15 16:25, John Garry wrote:
On 14/07/2026 13:06, yangxingui wrote:
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.

I am saying that other drivers use sas_resume_ha() and you are changing the behavior of that function - how can you guarantee that you are not causing regression for that those other drivers?

Good question. I didn't explain this in detail before. The reorder changes one thing for isci and pm8001 (the
only other drivers that call sas_resume_ha()): the PHYE_RESUME_TIMEOUT
handler now runs asynchronously after resume returns, instead of being
synchronized by sas_drain_work() within resume.

This does not cause a regression because I/O to timed-out phys is
already rejected before reaching hardware, regardless of ordering.
During suspend, sas_suspend_devices() calls sas_notify_lldd_dev_gone()
for each device, which sets dev->lldd_dev to NULL. So when
scsi_unblock_requests re-enables I/O in resume:
- isci: isci_lookup_device() returns NULL (lldd_dev is NULL) →
isci_task_refuse(SAS_DEVICE_UNKNOWN) → mapped to DID_BAD_TARGET
- pm8001: DEV_IS_GONE(pm8001_dev) is true (lldd_dev is NULL) →
returns SAS_PHY_DOWN → mapped to DID_NO_CONNECT
Both complete directly via scsi_done() — I/O never reaches hardware,
and this is identical in the old and new ordering since lldd_dev_gone
runs during suspend, before resume even begins.

For healthy phys that did resume in time, I/O proceeds normally in
both orderings — the earlier unblock just lets it start sooner.
aic94xx and mvsas don't register any PM ops, so they never call
sas_resume_ha() and are unaffected.

I'll include this analysis in the v3 commit message.

Thanks,
Xingui