Re: [Comments Needed] scan vs remove_target deadlock

[James Smart <James.Smart@Emulex.Com>]

Thanks Stefan...

> Another driver which uses a block/unblock interface is sbp2. It blocks
> shosts (because one shost == one SBP-2 LU at the moment) during 1394 bus
> reset/ 1394 nodes rescan/ SBP-2 reconnect phases. I learned the hard way
> that an shost (or sdev if you will) *must not be blocked* when an shost
> (or sdev) is to be removed.

True. The FC transport explicitly performs an unblock prior to the remove
call. However, the remove is then deadlocking on the scan_mutext vs the
pending request queue (still trying to find out why it's really stuck).

> IOW before a transport may remove an sdev or shost, it has to unblock it
> and it also has to make sure that all commands that were enqueued before
> the blocking are being completed.

True. The FC transport explicitly performs an unblock prior to the remove
call. What I'm seeing would align with "not" making sure the prior queued
commands are completed before it removes.

 > But isn't it rather a responsibility
> of the SCSI core to get a LU's or target's state transitions right?

Agreed. The real issue is - define the window for prior queued commands.
You may flush all that are there right now, but that may immediately
requeue a retry, etc - which means you have to start all over.

 > When
> an sdev is "blocked" and the transport tells the core to transition it
> to "to be removed", then the core should know that the sdev's LU cannot
> be reached anymore and act accordingly.

I would assume - that's what we'll eventually get to, with the mutex
being the first onion layer to get pulled.

-- james s