[dm-devel] [PATCH 1/9] blk: Do not abort requests if queue is stopped
Mike Anderson
andmike at linux.vnet.ibm.com
Wed May 5 04:52:31 UTC 2010
Jens Axboe <jens.axboe at 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 at linux.vnet.ibm.com>
> > Cc: Jens Axobe <jens.axboe at 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 at linux.vnet.ibm.com
More information about the dm-devel
mailing list