On Mon, May 03 2010, Mike Anderson wrote: > If the queue is stopped it could be an indication that other recovery is > happening in this case skip the blk_abort_request. > > Signed-off-by: Mike Anderson <andmike@xxxxxxxxxxxxxxxxxx> > Cc: Jens Axobe <jens.axboe@xxxxxxxxxx> > --- > block/blk-timeout.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/block/blk-timeout.c b/block/blk-timeout.c > index 1ba7e0a..89fbe0a 100644 > --- a/block/blk-timeout.c > +++ b/block/blk-timeout.c > @@ -224,7 +224,8 @@ void blk_abort_queue(struct request_queue *q) > list_splice_init(&q->timeout_list, &list); > > list_for_each_entry_safe(rq, tmp, &list, timeout_list) > - blk_abort_request(rq); > + if (!blk_queue_stopped(q)) > + blk_abort_request(rq); > > /* > * Occasionally, blk_abort_request() will return without That seems like a bit of a mixup, what ties a stopped queue to recovery? To take one example, the cciss driver stops the queue when it can't queue more at the hw level and starts it on completion to queue more. If recovery triggers when the hw queue has been filled, then timeouts will fail? It would be better to mark the queue as already doing abort. That state could be in the queue, or it could be at the driver level. -- Jens Axboe -- 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
