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. Bart.
