Re: [Comments Needed] scan vs remove_target deadlock

[Michael Reed <mdr@sgi.com>]

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
>