> On Apr 25, 2017, at 1:59 PM, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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
