[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56097878.2030000@kernel.dk>
Date: Mon, 28 Sep 2015 11:27:20 -0600
From: Jens Axboe <axboe@...nel.dk>
To: Roman Pen <r.peniaev@...il.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] blk-core: fix queue stuck on attempt to submit
request from unplug
On 09/27/2015 02:44 PM, Roman Pen wrote:
> In case of several stacked block devices, which both were inited by
> blk_init_queue call, you can catch the queue stuck, if first device
> in stack makes bio submit being in a flush of a plug list.
>
> Let's consider this regular scenario taking readahead into account
> (readahead.c:read_pages):
>
> 1. Start plug
> 2. Read pages in loop
> 3. Finish plug
>
> This example generates backtrace as follows:
>
> 1. blk_start_plug
> 2. generic_make_request
> q->make_request_fn
> [blk_queue_bio]
> if (current->plug)
> list_add_tail(&req->queuelist, &plug->list);
> 3. blk_finish_plug
> blk_flush_plug_list
> queue_unplugged
> __blk_run_queue
> XXX_request_fn [some request handler of block device]
> generic_make_request
> q->make_request_fn
> [blk_queue_bio]
> if (current->plug)
> list_add_tail(&req->queuelist, &plug->list);
>
> So the problem is, that on step 3. XXX_request_fn makes
> another request, which again will be put to plug list,
> because plug is till active, thus new request will be
> stuck forever in the queue.
>
> How to fix?
> Do flush plug list till it becomes empty.
What devices submit IO from request_fn? Seems like something that would
be better handled out of a make_request_fn hook for that device, which
would also avoid this corner case.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists