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.
