[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f85cb4a-8b14-623f-eb4e-40baab1ed888@acm.org>
Date: Wed, 14 Jun 2023 11:04:55 -0700
From: Bart Van Assche <bvanassche@....org>
To: Alan Stern <stern@...land.harvard.edu>,
Damien Le Moal <dlemoal@...nel.org>
Cc: Hannes Reinecke <hare@...e.de>,
Joe Breuer <linux-kernel@...reuer.net>,
Bagas Sanjaya <bagasdotme@...il.com>,
Pavel Machek <pavel@....cz>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <len.brown@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...omium.org>,
Tony Luck <tony.luck@...el.com>,
"Guilherme G. Piccoli" <gpiccoli@...lia.com>,
Thorsten Leemhuis <linux@...mhuis.info>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Phillip Potter <phil@...lpotter.co.uk>,
Linux Power Management <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Hardening <linux-hardening@...r.kernel.org>,
Linux Regressions <regressions@...ts.linux.dev>,
Linux SCSI <linux-scsi@...r.kernel.org>,
Dan Williams <dan.j.williams@...el.com>,
Hannes Reinecke <hare@...e.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Martin Kepplinger <martin.kepplinger@...i.sm>,
Kai-Heng Feng <kai.heng.feng@...onical.com>
Subject: Re: Fwd: Waking up from resume locks up on sr device
On 6/14/23 07:26, Alan Stern wrote:
> On Wed, Jun 14, 2023 at 04:35:50PM +0900, Damien Le Moal wrote:
>> Or... Why the heck scsi_rescan_device() is calling device_lock() ? This
>> is the only place in scsi code I can see that takes this lock. I suspect
>> this is to serialize either rescans, or serialize with resume, or both.
>> For serializing rescans, we can use another lock. For serializing with
>> PM, we should wait for PM transitions...
>> Something is not right here.
>
> Here's what commit e27829dc92e5 ("scsi: serialize ->rescan against
> ->remove", written by Christoph Hellwig) says:
>
> Lock the device embedded in the scsi_device to protect against
> concurrent calls to ->remove.
>
> That's the commit which added the device_lock() call.
Even if scsi_rescan_device() would use another mechanism for
serialization against sd_remove() and sr_remove(), we still need to
solve the issue that the ATA code calls scsi_rescan_device() before
resuming has finished. scsi_rescan_device() issues I/O. Issuing I/O to a
device is not allowed before that device has been resumed.
Thanks,
Bart.
Powered by blists - more mailing lists