lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ