Michael Reed wrote:
The remove is not for the target which holds the scsi host's scan mutex. Hence, the unblock doesn't kick the [right] queue.
Certainly could be true.
I think this means that transport cannot call scsi_remove_target() for any target if a scan is running. So, transport has to wait until it can assure that no scan is running, perhaps a new mutex, and has to have a way of kicking a blocked target which is being scanned, either when the LLDD unblocks the target or the delete work for that target fires.
Well - that's one way. Very difficult for the transport to know when this is true (not all scans occur from the transport). It should be a midlayer thing to ensure the proper things happen. Also highlights just how gross the that scan_lock is - which is where the real fix should be, although this will be a rats nest. -- james s - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
