Re: [RFC] scsi: reduce protection of scan_mutex in scsi_remove_device

Song Liu
2017-04-25T21:30:20Z

> On Apr 25, 2017, at 1:59 PM, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:
>
> On Fri, 2017-04-21 at 22:31 +0000, Song Liu wrote:
>> On Apr 21, 2017, at 2:20 PM, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:
>>> On Fri, 2017-04-21 at 14:13 -0700, Song Liu wrote:
>>>> On the other hand, some devices do long latency IO during deletion,
>>>> for example, sd_shutdown() may do sync cache and/or start_stop.
>>>> It is not necessary for these commands to run in series.
>>>
>>> Have you noticed my patch series that makes sd_shutdown() submit the
>>> SYNCHRONIZE CACHE command asynchronously? Have you tried whether that
>>> patch series would be a good alternative?
>>
>> The asynchronous SYNCHRONIZE CACHE will not help our use case, where the
>> latency comes from sd_start_stop_device(). Seems it is not easy to make
>> the START STOP UNIT command async.
>
> Hello Song,
>
> It should be possible to make the START STOP UNIT command asynchronous too
> by issuing it asynchronously from inside sd_sync_cache_done(). To avoid
> dereferencing a stale struct scsi_disk pointer you will either have to hold
> an additional reference as long as the SYNCHRONIZE CACHE command is in
> progress or copy the data needed from struct scsi_disk into the SCSI request.
>

Hello Bart,

As you stated in the patch: blk_cleanup_queue() in __scsi_remove_device()
will wait for async SYNCHRONIZE CACHE and START STOP UNIT command to complete.
Since __scsi_remove_device() is called with scan_mutex held, simultaneous
START STOP UNIT requires are still serialized by the scan_mutex.

Song