From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Jason Yan <yanaijie@huawei.com>,
John Garry <john.g.garry@oracle.com>,
Xingui Yang <yangxingui@huawei.com>,
jejb@linux.ibm.com, martin.petersen@oracle.com,
niklas.cassel@wdc.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxarm@huawei.com, prime.zeng@hisilicon.com,
kangfenglong@huawei.com
Subject: Re: [PATCH] scsi: libsas: Grab the host lock in sas_ata_device_link_abort()
Date: Wed, 21 Dec 2022 17:31:59 +0900 [thread overview]
Message-ID: <f77c7872-3711-2216-c17c-e23591f745c7@opensource.wdc.com> (raw)
In-Reply-To: <755d7a9c-427e-024a-8509-449ebc5a00e6@huawei.com>
On 12/21/22 15:35, Jason Yan wrote:
> On 2022/12/21 11:59, Damien Le Moal wrote:
>> On 2022/12/21 11:42, Jason Yan wrote:
>>> On 2022/12/21 8:36, Damien Le Moal wrote:
>>>> On 2022/12/20 23:59, John Garry wrote:
>>>>> On 20/12/2022 12:53, Xingui Yang wrote:
>>>>>> Grab the host lock in sas_ata_device_link_abort() before calling
>>>>>
>>>>> This is should be the ata port lock, right? I know that the ata
>>>>> comments
>>>>> say differently.
>>>>>
>>>>>> ata_link_abort(), as the comment in ata_link_abort() mentions.
>>>>>>
>>>>>
>>>>> Can you please add a fixes tag?
>>>>>
>>>>>> Signed-off-by: Xingui Yang <yangxingui@huawei.com>
>>>>>
>>>>> Reviewed-by: John Garry <john.g.garry@oracle.com>
>>>>>
>>>>>> ---
>>>>>> drivers/scsi/libsas/sas_ata.c | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/scsi/libsas/sas_ata.c
>>>>>> b/drivers/scsi/libsas/sas_ata.c
>>>>>> index f7439bf9cdc6..4f2017b21e6d 100644
>>>>>> --- a/drivers/scsi/libsas/sas_ata.c
>>>>>> +++ b/drivers/scsi/libsas/sas_ata.c
>>>>>> @@ -889,7 +889,9 @@ void sas_ata_device_link_abort(struct
>>>>>> domain_device *device, bool force_reset)
>>>>>> {
>>>>>> struct ata_port *ap = device->sata_dev.ap;
>>>>>> struct ata_link *link = &ap->link;
>>>>>> + unsigned long flags;
>>>>>> + spin_lock_irqsave(ap->lock, flags);
>>>>>> device->sata_dev.fis[2] = ATA_ERR | ATA_DRDY; /* tf status */
>>>>>> device->sata_dev.fis[3] = ATA_ABORTED; /* tf error */
>>>>>> @@ -897,6 +899,7 @@ void sas_ata_device_link_abort(struct
>>>>>> domain_device *device, bool force_reset)
>>>>>> if (force_reset)
>>>>>> link->eh_info.action |= ATA_EH_RESET;
>>>>>> ata_link_abort(link);
>>>>
>>>> Really need to add lockdep annotations in libata to avoid/catch such
>>>> bugs...
>>>> Will work on that.
>>>
>>> Actually in libata there are many places calling ata_link_abort() not
>>> holding port lock. And some places are holding the real host
>>> lock(ata_host->lock) while calling ata_link_abort(). So if you add the
>>> lockdep annotations, there may be too many warnings. If these are real
>>> issues, we should fix them first.
>>
>> libata-EH does most of its work without the port lock held because by
>> the time
>> we get EH started, we are guaranteed to be idle with no commands in
>> flight. That
>> is why the calls you mention look like "bugs" but are not.
>
> What about the interrupt handler such as ahci_error_intr()? I didn't see
> the callers hold the port lock too. Do they need the port lock?
It looks like it is missing for ahci_thunderx_irq_handler() but that one
takes the host lock. Same for xgene_ahci_irq_intr(), again no port lock
but host lock taken. And again for ahci_single_level_irq_intr() for the
non MSI case. For modern MSI adapters, the port lock is taken in
For other cases, ahci_multi_irqs_intr_hard) takes the port lock.
So it looks like ahci_port_intr() needs to take the lock and some
cleanups overall (the host lock should not be necessary in the command
path. But nobody seems to have issues with the "bad" cases... Probably
because they are not mainstream adapters.
Definitely some work needed here.
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-12-21 8:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-20 12:53 [PATCH] scsi: libsas: Grab the host lock in sas_ata_device_link_abort() Xingui Yang
2022-12-20 14:59 ` John Garry
2022-12-21 0:36 ` Damien Le Moal
2022-12-21 2:42 ` Jason Yan
2022-12-21 3:59 ` Damien Le Moal
2022-12-21 6:35 ` Jason Yan
2022-12-21 8:31 ` Damien Le Moal [this message]
2022-12-21 9:44 ` Niklas Cassel
2022-12-21 12:24 ` Damien Le Moal
2022-12-21 1:47 ` 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=f77c7872-3711-2216-c17c-e23591f745c7@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=jejb@linux.ibm.com \
--cc=john.g.garry@oracle.com \
--cc=kangfenglong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=niklas.cassel@wdc.com \
--cc=prime.zeng@hisilicon.com \
--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