James Smart wrote: > 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 don't think it would deadlock if it wasn't. The scan mutex is a rather gross lock. > >> 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. There's fc_user_scan() which I believe handles scans initiated via the sysfs/proc variables. There's fc_scsi_scan_rport() run via the scan work. It appears that the routines that perform a scan, in a fibre channel context, are all entered via the transport. What am I missing? Mike > > -- 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
