This patch series has three sections explained below. The patches are
presented as a series as they hit some common functions and may need to
be applied in order to avoid conflicts.
1.) Avoid possibly waking up the error handler on a queue that it stopped.
blk: Do not abort requests if queue is stopped
2.) It is possible to have a request on the elevator that is already
prepped. The prepped resources should be released also. This was seen under
heavy IO load while a lot of requeue activity as going occurring.
blk: In elv_abort_queue skip requests with REQ_DONTPREP set
blk: Add a unprep_rq_fn
blk: Call unprep_fn from elv_abort_queue is available
scsi: Add a scsi_unprep_fn
3.) These four patches add a flag to a request indicating that a block
abort has been called on the request. It also adds a common
scsi_requeue_request so that the flag can be checked in only one location
on a attempt to requeue.
Currently we may abort a request and post error recovery the request can
be requeued. We may also try to abort a request that is in the process of
completing that we would like to prevent a requeue on.
The abort flag is different than a fast fail flag in that it is provides a
hint that the request should be returned as soon as possible (i.e. do not
requeue even if disposition indicates that it would be allowed).
The change allowed failovers that where exceeding (SD_MAX_RETRIES * IO
TIMEOUT) to be able to failover in less than a single timeout (the less
than case depended on the type of event that triggered the path failure).
blk: Add request atomic flag for abort
blk: Mark requests aborted
scsi: Add scsi_requeue_request function
scsi: Add blk_request_aborted check
I tested the patches on a IBM,2105800 connected through a zfcp adapter,
a IBM,1815 through a qlogic adapter, and scsi_debug.