Re: [PATCH 1/9] blk: Do not abort requests if queue is stopped

[Mike Anderson <andmike@linux.vnet.ibm.com>]

Jens Axboe <jens.axboe@oracle.com> wrote:
> 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@linux.vnet.ibm.com>
> > Cc: Jens Axobe <jens.axboe@oracle.com>
> > ---
> >  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?

This was coding to SCSI behavior again. I tried to reduce the case of
waking the eh if the transport moved the target into a blocked state. It
might be redundant as FC has eh blocking and timer_reset. iSCSI has
blocking but not eh blocking.

> 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.

ok. I will look into this.

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com