> On Apr 25, 2017, at 10:52 AM, Bart Van Assche <Bart.VanAssche@xxxxxxxxxxx> 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
