Re: [PATCH 4/4] fc class: use transport host byte values

[Mike Christie <michaelc@cs.wisc.edu>]

James Smart wrote:
> Background:
>   The states, in the transport are:
>      event               state
>     --------------------------------
>       n/a                running
>     lose connectivity    blocked
>     fastfail timeout     still blocked, but with fastfail indicator

My patch changed this one. When this times out, I unblock the queue.

>     dev_loss timeout     unblocked/removed
> 
> Question:
> 
> The chkready helper in the transport catches race conditions where the
> block is being put in place, but queuecommand is running on another cpu,
> thus returning DID_IMM_RETRY.
> 
> Your patch is updating chkready to look for the case when fastfail has
> fired, and returning DID_TRANSPORT_FASTFAIL  ?  Why ?  The request
> queue would be blocked so there should be no call to queuecommand that
> would fall into this category - unless you are assuming that fastfail
> timeout is so fast that it could fall into the same race condition as
> blocked.

In the patch, when the fast IO fail timer fires, I unblock the queues.

+       rport->fast_io_fail_timeout = 1;
        i->f->terminate_rport_io(rport);
+       scsi_target_unblock(&rport->dev);

At that time IO would be queued on drivers and would hit that test and
be failed. New IO would also be failed upwards by that check.