Background: The states, in the transport are: event state -------------------------------- n/a running lose connectivity blocked fastfail timeout still blocked, but with fastfail indicator 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. What I think is right is - DID_TRANSPORT_FASTFAIL only is returned by the drivers on the i/o they kill as part of the terminate_io function invoked by fastfail (or on the new block queue kill request I mentioned an email ago). There should be no reason to add it to chkready unless you are trying to be absolutely protective for the above race conditions. (and hey - it makes sense that if you involve the request queue to kill all io at fast fail, there won't be any io to call queuecommand for, and even if it did get through, it'll be marked for requeuing to the request queue who will note the fastfail kill has been called and can immediately give it back to the upper layers with the proper status). -- james s - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html