From: Damien Le Moal <dlemoal@kernel.org>
To: Bart Van Assche <bvanassche@acm.org>,
Bagas Sanjaya <bagasdotme@gmail.com>, Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Kees Cook <keescook@chromium.org>,
Tony Luck <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
Thorsten Leemhuis <linux@leemhuis.info>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Phillip Potter <phil@philpotter.co.uk>,
Joe Breuer <linux-kernel@jmbreuer.net>,
Linux Power Management <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Hardening <linux-hardening@vger.kernel.org>,
Linux Regressions <regressions@lists.linux.dev>,
Linux SCSI <linux-scsi@vger.kernel.org>,
Alan Stern <stern@rowland.harvard.edu>,
Dan Williams <dan.j.williams@intel.com>,
Hannes Reinecke <hare@suse.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Martin Kepplinger <martin.kepplinger@puri.sm>,
Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: Re: Fwd: Waking up from resume locks up on sr device
Date: Mon, 12 Jun 2023 12:09:29 +0900 [thread overview]
Message-ID: <4005a768-9e45-0707-509d-98ce0d2769bd@kernel.org> (raw)
In-Reply-To: <02e4f87a-80e8-dc5d-0d6e-46939f2c74ac@acm.org>
On 6/11/23 00:03, Bart Van Assche wrote:
> On 6/10/23 06:27, Bagas Sanjaya wrote:
>> On 6/10/23 15:55, Pavel Machek wrote:
>>>>> #regzbot introduced: v5.0..v6.4-rc5 https://bugzilla.kernel.org/show_bug.cgi?id=217530
>>>>> #regzbot title: Waking up from resume locks up on SCSI CD/DVD drive
>>>>>
>>>> The reporter had found the culprit (via bisection), so:
>>>>
>>>> #regzbot introduced: a19a93e4c6a98c
>>> Maybe cc the authors of that commit?
>>
>> Ah! I forgot to do that! Thanks anyway.
>
> Hi Damien,
>
> Why does the ATA code call scsi_rescan_device() before system resume has
> finished? Would ATA devices still work with the patch below applied?
I do not know the PM code well at all, need to dig into it. But your patch
worries me as it seems it would prevent rescan of the device on a resume, which
can be an issue if the device has changed.
I am not yet 100% clear on the root cause for this, but I think it comes from
the fact that ata_port_pm_resume() runs before the sci device resume is done, so
with scsi_dev->power.is_suspended still true. And ata_port_pm_resume() calls
ata_port_resume_async() which triggers EH (which will do reset + rescan)
asynchronously. So it looks like we have scsi device resume and libata EH for
rescan fighting each others for the scan mutex and device lock, leading to deadlock.
Trying to recreate this issue now to confirm and debug further. But I suspect
the solution to this may be best implemented in libata, not in scsi.
This looks definitely related to this thread:
https://lore.kernel.org/linux-scsi/7b553268-69d3-913a-f9de-28f8d45bdb1e@acm.org/
Similaraly to your comment on that thread, having to look at
dev->power.is_suspended is not ideal I think. What we need is to have ata and
scsi pm resume be synchronized, but I am not yet 100% clear on the scsi layer side.
>
> Thanks,
>
> Bart.
>
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6a959c993dd8..be3971b7fd27 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -1629,6 +1629,20 @@ void scsi_rescan_device(struct device *dev)
> {
> struct scsi_device *sdev = to_scsi_device(dev);
>
> +#ifdef CONFIG_PM_SLEEP
> + /*
> + * The ATA subsystem may call scsi_rescan_device() before resuming has
> + * finished. If this happens, prevent a deadlock on the device_lock()
> + * call by skipping rescanning.
> + */
> + if (dev->power.is_suspended)
> + return;
> +#endif
> +
> + /*
> + * Serialize scsi_driver.rescan() calls and scsi_driver.gendrv.remove()
> + * calls.
> + */
> device_lock(dev);
>
> scsi_attach_vpd(sdev);
>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2023-06-12 3:11 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-09 11:04 Fwd: Waking up from resume locks up on sr device Bagas Sanjaya
2023-06-10 6:38 ` Bagas Sanjaya
2023-06-10 8:55 ` Pavel Machek
2023-06-10 13:27 ` Bagas Sanjaya
2023-06-10 15:03 ` Bart Van Assche
2023-06-11 9:05 ` Joe Breuer
2023-06-11 11:31 ` Bagas Sanjaya
2023-06-14 4:49 ` Damien Le Moal
2023-06-14 5:37 ` Kai-Heng Feng
2023-06-14 6:31 ` Damien Le Moal
2023-06-14 7:22 ` Damien Le Moal
2023-06-14 6:57 ` Hannes Reinecke
2023-06-14 7:35 ` Damien Le Moal
2023-06-14 14:26 ` Alan Stern
2023-06-14 14:40 ` Rafael J. Wysocki
2023-06-14 18:04 ` Bart Van Assche
2023-06-14 22:44 ` Damien Le Moal
2023-06-15 0:10 ` Damien Le Moal
2023-06-15 4:40 ` Christoph Hellwig
2023-06-15 4:57 ` Damien Le Moal
2023-06-15 5:09 ` Christoph Hellwig
2023-06-12 3:09 ` Damien Le Moal [this message]
2023-06-12 6:09 ` Hannes Reinecke
2023-06-12 7:22 ` Damien Le Moal
2023-06-12 7:36 ` Kai-Heng Feng
2023-06-12 7:47 ` Damien Le Moal
2023-06-12 14:33 ` Alan Stern
2023-06-12 15:37 ` Rafael J. Wysocki
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=4005a768-9e45-0707-509d-98ce0d2769bd@kernel.org \
--to=dlemoal@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=bagasdotme@gmail.com \
--cc=bvanassche@acm.org \
--cc=dan.j.williams@intel.com \
--cc=gpiccoli@igalia.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.com \
--cc=jejb@linux.ibm.com \
--cc=kai.heng.feng@canonical.com \
--cc=keescook@chromium.org \
--cc=len.brown@intel.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@jmbreuer.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux@leemhuis.info \
--cc=martin.kepplinger@puri.sm \
--cc=martin.petersen@oracle.com \
--cc=pavel@ucw.cz \
--cc=phil@philpotter.co.uk \
--cc=rafael@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=stern@rowland.harvard.edu \
--cc=tony.luck@intel.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;
as well as URLs for NNTP newsgroup(s).