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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
