mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: John Garry <john.garry@linux.dev>
To: yangxingui <yangxingui@huawei.com>,
	yanaijie@huawei.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, mkp@kernel.org
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxarm@huawei.com, liuyonglong@huawei.com,
	kangfenglong@huawei.com
Subject: Re: [PATCH] scsi: libsas: Fix SMP IO deadlock during HA resume
Date: Wed, 16 Sep 2026 14:58:02 +0100	[thread overview]
Message-ID: <2c1aee3c-3ea5-44f7-915c-5a812a261032@linux.dev> (raw)
In-Reply-To: <a97c6cfb-8476-1030-a07a-fea1c004ecbe@huawei.com>

On 9/11/26 02:00, yangxingui wrote:
> Hi John & Jason,
> 
> Kindly ping for review...

What about the sashiko comment:

- [High] Bypassing PM reference counting via a global state flag creates 
a race condition where concurrent independent threads can submit SMP 
I/Os without holding a PM reference, risking premature hardware suspend.

It looks correct.

> 
> On 2026/8/26 11:28, Xingui Yang wrote:
>> During sas_resume_ha() -> sas_drain_work(), 

This is poorly described - what does during sas_resume_ha() -> 
sas_drain_work() even mean?

> ATA EH will trigger SMP 
>> IOs via
>> sas_phy_reset() -> sas_smp_phy_control() for expander-attached ATA 
>> devices.

What commands are these specifically?

>> Since ha->dev is RPM_RESUMING at that point, pm_runtime_get_sync() blocks
>> waiting for the resume to finish, but the resume is blocked in
>> sas_drain_work() waiting for the SMP IO — a deadlock.
>>
>> Skip the PM get/put when SAS_HA_RESUMING is set. The hardware is already
>> initialized by the LLDD resume callback before sas_resume_ha() runs, 
>> so no
>> explicit resume is needed.
>>
>> Only hisi_sas enables runtime PM among libsas LLDDs, so other drivers
>> (pm8001, isci, aic94xx, mvsas) are unaffected.
>>
>> Fixes: 0da7ca4c4fd9 ("scsi: libsas: Resume host while sending SMP I/Os")
>> Signed-off-by: Xingui Yang <yangxingui@huawei.com>
>> ---
>>   drivers/scsi/libsas/sas_expander.c | 16 +++++++++++++---
>>   1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/ 
>> sas_expander.c
>> index 811c9eb4fef1..77ae2ae7b2c4 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -61,8 +61,17 @@ static int smp_execute_task_sg(struct domain_device 
>> *dev,
>>       struct sas_internal *i =
>>           to_sas_internal(dev->port->ha->shost->transportt);
>>       struct sas_ha_struct *ha = dev->port->ha;
>> -
>> -    pm_runtime_get_sync(ha->dev);
>> +    bool skip_pm = test_bit(SAS_HA_RESUMING, &ha->state);
>> +
>> +    /*
>> +     * Skip PM get/put during HA resume to avoid deadlock: the host is
>> +     * RPM_RESUMING and the drain waits for this SMP IO to finish, but
>> +     * pm_runtime_get_sync() would block on RPM_RESUMING. Safe because
>> +     * hardware is already initialized by the LLDD before call
>> +     * sas_resume_ha().
>> +     */
>> +    if (!skip_pm)
>> +        pm_runtime_get_sync(ha->dev);
>>       mutex_lock(&dev->ex_dev.cmd_mutex);
>>       for (retry = 0; retry < 3; retry++) {
>>           if (test_bit(SAS_DEV_GONE, &dev->state)) {
>> @@ -135,7 +144,8 @@ static int smp_execute_task_sg(struct 
>> domain_device *dev,
>>           }
>>       }
>>       mutex_unlock(&dev->ex_dev.cmd_mutex);
>> -    pm_runtime_put_sync(ha->dev);
>> +    if (!skip_pm)
>> +        pm_runtime_put_sync(ha->dev);
>>       BUG_ON(retry == 3 && task != NULL);
>>       sas_free_task(task);
>>


  reply	other threads:[~2026-09-16 13:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-26  3:28 Xingui Yang
2026-09-11  1:00 ` yangxingui
2026-09-16 13:58   ` John Garry [this message]
2026-09-17  9:36     ` yangxingui

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2c1aee3c-3ea5-44f7-915c-5a812a261032@linux.dev \
    --to=john.garry@linux.dev \
    --cc=jejb@linux.ibm.com \
    --cc=kangfenglong@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=liuyonglong@huawei.com \
    --cc=martin.petersen@oracle.com \
    --cc=mkp@kernel.org \
    --cc=yanaijie@huawei.com \
    --cc=yangxingui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®