linux-kernel - Re: blk-mq flush fix

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-next>] [day] [month] [year] [list]

Date:	Mon, 28 Oct 2013 13:38:57 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	Shaohua Li <shli@...nel.org>
CC:	Christoph Hellwig <hch@...radead.org>,
	Alexander Gordeev <agordeev@...hat.com>,
	Tejun Heo <tj@...nel.org>,
	Nicholas Bellinger <nab@...ux-iscsi.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: blk-mq flush fix

On 10/28/2013 10:57 AM, Shaohua Li wrote:
> 
> 
> 
> 2013/10/28 Jens Axboe <axboe@...nel.dk <mailto:axboe@...nel.dk>>
> 
>     On 10/28/2013 02:48 AM, Christoph Hellwig wrote:
>     > On Sun, Oct 27, 2013 at 10:29:25PM +0000, Jens Axboe wrote:
>     >> On Sat, Oct 26 2013, Christoph Hellwig wrote:
>     >>> I think this variant of the patch from Alexander should fix the
>     issue
>     >>> in a minimally invasive way.  Longer term I'd prefer to use
>     q->flush_rq
>     >>> like in the non-mq case by copying over the context and tag
>     information.
>     >>
>     >> This one is pretty simple, we could definitely use it as a band
>     aid. I
>     >> too would greatly prefer using the static ->flush_rq instead.
>     Just have
>     >> it marked to bypass most of the free logic.
>     >
>     > We already bypass the free logical by setting and end_io callback for
>     > a while, similar to what the old code does.  Maybe it's not all that
>     > hard to prealloc the request, let me give a sping.  Using the static
>     > allocated one will be hard due to the driver-specific extra data,
>     > though.
> 
>     It's not that I think the existing patch is THAT bad, it fits in alright
>     with the reserved tagging and works regardless of whether a driver uses
>     reserved tags or not. And it does have the upside of not requiring
>     special checks or logic for this special non-tagged request that using
>     the preallocated would might need.
> 
>     >> I'll add this one.
>     >
>     > Gimme another day or so to figure this out.
> 
>     OK, holding off.
> 
> 
> Another option: we could throttle flush-request allocation in
> blk_mq_alloc_request(), for example, flush_req_nr >= max_tags - 1, make
> the allocation wait.

That could work too. If we back off, then we could restart it once a
request completes. That does, however, requiring checking that and
potentially kicking all the queues on completion when that happens.

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