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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
