linux-kernel - Re: [PATCH 0/2] Introduce the request handling for dm-crypt

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:	Wed, 11 Nov 2015 13:18:13 -0500
From:	Mike Snitzer <snitzer@...hat.com>
To:	Baolin Wang <baolin.wang@...aro.org>
Cc:	axboe@...nel.dk, agk@...hat.com, dm-devel@...hat.com,
	neilb@...e.com, linux-raid@...r.kernel.org, jack@...e.cz,
	arnd@...db.de, linux-kernel@...r.kernel.org, keith.busch@...el.com,
	jmoyer@...hat.com, broonie@...nel.org, tj@...nel.org,
	bart.vanassche@...disk.com, dineshg@...cinc.com
Subject: Re: [PATCH 0/2] Introduce the request handling for dm-crypt

On Wed, Nov 11 2015 at  4:31am -0500,
Baolin Wang <baolin.wang@...aro.org> wrote:

> Now the dm-crypt code only implemented the 'based-bio' method to encrypt/
> decrypt block data, which can only hanle one bio at one time. As we know,
> one bio must use the sequential physical address and it also has a limitation
> of length. Thus it may limit the big block encyrtion/decryption when some
> hardware support the big block data encryption.
> 
> This patch series introduc the 'based-request' method to handle the data
> encryption/decryption. One request can contain multiple bios, so it can
> handle big block data to improve the efficiency.

The duality of bio-based vs request-based code paths in DM core frankly
sucks.  So the prospect of polluting dm-crypt with a similar duality is
really _not_ interesting.

Request-based DM requires more memory reserves per device than bio-based
DM.  Also, you cannot stack request-based DM ontop of bio-based devices
(be them DM, MD, etc) so request-based DM's underlying storage stack
gets a lot less interesting with this change.

That said, it could be that the benefits of supporting both bio-based
and request-based DM in dm-crypt outweigh any overhead/limitations.  But
you haven't given any performance data to justify this patchset.

There needs to be a _really_ compelling benefit to do this.

Also, FYI, having a big CONFIG knob to switch all of dm-crypt from
bio-based to request-based is _not_ acceptable.  Both modes would need
to be supported in parallel.  Could easily be that not all devices in a
system will benefit from being request-based.

Regardless, the risk of this change causing request-based DM to become
more brittle than it already is concerns me.

But I'm trying to keep an open mind... show me data that real hardware
_really_ benefits and we'll go from there.  Again, it needs to be "OMG,
this is amazing!" level performance to warrant any further serious
consideration.
--
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/