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

Song Liu
2017-04-25T21:18:40Z

> On Apr 25, 2017, at 10:52 AM, Bart Van Assche <Bart.VanAssche@sandisk.com> wrote:
>
> On Tue, 2017-04-25 at 17:42 +0000, Song Liu wrote:
>> I have been studying the code recently. I am wondering whether the following
>> would work:
>>
>> 1. Introduce a new mutex for scsi_device to protect most operations in the
>> list you gathered above;
>>
>> 2. For operations like host->slave_destroy(), ensure they access scsi_host
>> data with host_lock (or another spin lock).
>>
>> I looked into all instances of slave_destroy, only 2 of them:
>> dc395x_slave_destroy() and visorhba_slave_destroy() access scsi_host data
>> without protection of spin lock.
>>
>> 3. Once 1 and 2 is ready, __scsi_remove_device() only need to hold the mutex
>> for the scsi_device. scan_mutex is no longer required.
>>
>> Is this a valid path?
>
> Sorry but I don't think so. Unlocking and reacquiring scan_mutex would create
> the potential that LUN scanning occurs in the meantime and hence that it fails
> because LUN removal is incomplete.
>

Hello Bart,

I am not sure I fully understand the problem here. If I understand the logic
correctly, when a device is being removed, it will stay in scsi_host->__devices
until fully the remove routine is finished. And LUN scanning in parallel will
find the device with scsi_device_lookup_by_target(), and thus it would not
rescan the device until the device is fully removed? Did I miss anything here?

Thanks,
Song