linux-kernel - Re: [PATCH V11 0/4] blk-mq: refactor code of issue directly

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Dec 2018 20:16:20 -0700
From:   Jens Axboe <axboe@...nel.dk>
To:     Jianchao Wang <jianchao.w.wang@...cle.com>
Cc:     ming.lei@...hat.com, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH V11 0/4] blk-mq: refactor code of issue directly

On 12/6/18 8:09 PM, Jianchao Wang wrote:
> Hi Jens
> 
> Please consider this patchset for 4.21.
> 
> It refactors the code of issue request directly to unify the interface
> and make the code clearer and more readable.
> 
> This patch set is rebased on the recent for-4.21/block and add the 1st
> patch which inserts the non-read-write request to hctx dispatch
> list to avoid to involve merge and io scheduler when bypass_insert
> is true, otherwise, inserting is ignored, BLK_STS_RESOURCE is returned
> and the caller will fail forever.
> 
> The 2nd patch refactors the code of issue request directly to unify the
> helper interface which could handle all the cases.
> 
> The 3rd patch make blk_mq_sched_insert_requests issue requests directly
> with 'bypass' false, then it needn't to handle the non-issued requests
> any more.
> 
> The 4th patch replace and kill the blk_mq_request_issue_directly.

Sorry to keep iterating on this, but let's default to inserting to
the dispatch list if we ever see busy from a direct dispatch. I'm fine
with doing that for 4.21, as suggested by Ming, I just didn't want to
fiddle with it for 4.20. This will prevent any merging on the request
going forward, which I think is a much safer default.

You do this already for some cases. Let's do it unconditionally for
a request that was ever subjected to ->queue_rq() and we didn't either
error or finish after the fact.

-- 
Jens Axboe