linux-kernel - Re: [RFC PATCH 0/1] dm-crypt excessive overhead

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:   Tue, 23 Jun 2020 11:22:36 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Ignat Korchagin <ignat@...udflare.com>
Cc:     Damien Le Moal <Damien.LeMoal@....com>,
        Mikulas Patocka <mpatocka@...hat.com>,
        "dm-crypt@...ut.de" <dm-crypt@...ut.de>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "agk@...hat.com" <agk@...hat.com>,
        "kernel-team@...udflare.com" <kernel-team@...udflare.com>
Subject: Re: [RFC PATCH 0/1] dm-crypt excessive overhead

On Tue, Jun 23 2020 at 11:07am -0400,
Ignat Korchagin <ignat@...udflare.com> wrote:

> Do you think it may be better to break it in two flags: one for read
> path and one for write? So, depending on the needs and workflow these
> could be enabled independently?

If there is a need to split, then sure.  But I think Damien had a hard
requirement that writes had to be inlined but that reads didn't _need_
to be for his dm-zoned usecase.  Damien may not yet have assessed the
performance implications, of not have reads inlined, as much as you
have.

So let's see how Damien's work goes and if he trully doesn't need/want
reads to be inlined then 2 flags can be created.

Mike