linux-kernel - Re: [PATCH PoCv2 0/2] mmc: add blk-mq support

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

Message-ID: <CACRpkdYEqbpU0sc+-CvJh32hnrM0G=SYQBhb5r34ofmYyBoD3g@mail.gmail.com>
Date:   Wed, 4 Jan 2017 11:18:14 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Paolo Valente <paolo.valente@...aro.org>,
        Jens Axboe <axboe@...com>, Hannes Reinecke <hare@...e.com>,
        Tejun Heo <tj@...nel.org>, Omar Sandoval <osandov@...ndov.com>,
        Christoph Hellwig <hch@....de>,
        Bart Van Assche <Bart.VanAssche@...disk.com>,
        Baolin Wang <baolin.wang@...aro.org>,
        Ritesh Harjani <riteshh@...eaurora.org>,
        Arnd Bergmann <arnd@...db.de>,
        Chunyan Zhang <zhang.chunyan@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        linux-block@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH PoCv2 0/2] mmc: add blk-mq support

On Tue, Jan 3, 2017 at 6:30 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@...sung.com> wrote:

Interesting patch!

> The differences between these patches and Linus' RFD patch:
> - request completion is handled from the IRQ handler
>   (or tasklet context as happens in dw_mmc host driver)

I think we need to make a patch like this separately to the
current (only old blk) code, to stop the kthread from forcing
in NULL requests to clean the pipeline.

We should also avoid sending any completion at
all: if we know we only get one request at a time as your
patch does, there is no reason to wait for a completion: we
will always be complete when a new request arrives.

Same with two requests in parallel, we can trust the block
layer to not send more than 2 (the queue depth) so there is
no reason to wait for a completion.

I'm trying to work in this direction at least, your patch is great
inspiration!

Yours,
Linus Walleij