From: Eric Biggers <ebiggers@kernel.org>
To: linux-crypto@vger.kernel.org, fsverity@lists.linux.dev,
dm-devel@lists.linux.dev
Cc: x86@kernel.org, linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ardb@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Bart Van Assche <bvanassche@acm.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>
Subject: [PATCH v6 10/15] dm-verity: provide dma_alignment limit in io_hints
Date: Fri, 21 Jun 2024 09:59:17 -0700 [thread overview]
Message-ID: <20240621165922.77672-11-ebiggers@kernel.org> (raw)
In-Reply-To: <20240621165922.77672-1-ebiggers@kernel.org>
From: Eric Biggers <ebiggers@google.com>
Since Linux v6.1, some filesystems support submitting direct I/O that is
aligned to only dma_alignment instead of the logical_block_size
alignment that was required before. I/O that is not aligned to the
logical_block_size is difficult to handle in device-mapper targets that
do cryptographic processing of data, as it makes the units of data that
are hashed or encrypted possibly be split across pages, creating rarely
used and rarely tested edge cases.
As such, dm-crypt and dm-integrity have already opted out of this by
setting dma_alignment to 'logical_block_size - 1'.
Although dm-verity does have code that handles these cases (or at least
is intended to do so), supporting direct I/O with such a low amount of
alignment is not really useful on dm-verity devices. So, opt dm-verity
out of it too so that it's not necessary to handle these edge cases.
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@google.com>
---
drivers/md/dm-verity-target.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 4ef814a7faf4..c6a0e3280e39 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -1021,10 +1021,12 @@ static void verity_io_hints(struct dm_target *ti, struct queue_limits *limits)
if (limits->physical_block_size < 1 << v->data_dev_block_bits)
limits->physical_block_size = 1 << v->data_dev_block_bits;
blk_limits_io_min(limits, limits->logical_block_size);
+
+ limits->dma_alignment = limits->logical_block_size - 1;
}
static void verity_dtr(struct dm_target *ti)
{
struct dm_verity *v = ti->private;
--
2.45.2
next prev parent reply other threads:[~2024-06-21 17:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-21 16:59 [PATCH v6 00/15] Optimize dm-verity and fsverity using multibuffer hashing Eric Biggers
2024-06-21 16:59 ` [PATCH v6 01/15] crypto: shash - add support for finup_mb Eric Biggers
2024-06-28 0:52 ` Herbert Xu
2024-06-21 16:59 ` [PATCH v6 02/15] crypto: testmgr - generate power-of-2 lengths more often Eric Biggers
2024-06-21 16:59 ` [PATCH v6 03/15] crypto: testmgr - add tests for finup_mb Eric Biggers
2024-06-21 16:59 ` [PATCH v6 04/15] crypto: x86/sha256-ni - add support " Eric Biggers
2024-06-21 16:59 ` [PATCH v6 05/15] crypto: arm64/sha256-ce " Eric Biggers
2024-06-21 16:59 ` [PATCH v6 06/15] fsverity: improve performance by using multibuffer hashing Eric Biggers
2024-06-21 16:59 ` [PATCH v6 07/15] dm-verity: move hash algorithm setup into its own function Eric Biggers
2024-06-21 16:59 ` [PATCH v6 08/15] dm-verity: move data hash mismatch handling " Eric Biggers
2024-06-21 16:59 ` [PATCH v6 09/15] dm-verity: make real_digest and want_digest fixed-length Eric Biggers
2024-06-21 16:59 ` Eric Biggers [this message]
2024-06-21 16:59 ` [PATCH v6 11/15] dm-verity: always "map" the data blocks Eric Biggers
2024-06-21 16:59 ` [PATCH v6 12/15] dm-verity: make verity_hash() take dm_verity_io instead of ahash_request Eric Biggers
2024-06-21 16:59 ` [PATCH v6 13/15] dm-verity: hash blocks with shash import+finup when possible Eric Biggers
2024-06-21 16:59 ` [PATCH v6 14/15] dm-verity: reduce scope of real and wanted digests Eric Biggers
2024-06-21 16:59 ` [PATCH v6 15/15] dm-verity: improve performance by using multibuffer hashing Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240621165922.77672-11-ebiggers@kernel.org \
--to=ebiggers@kernel.org \
--cc=agk@redhat.com \
--cc=ardb@kernel.org \
--cc=bvanassche@acm.org \
--cc=dm-devel@lists.linux.dev \
--cc=fsverity@lists.linux.dev \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=samitolvanen@google.com \
--cc=snitzer@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).