From: Eric Biggers <ebiggers@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH 8/9] blk-crypto: optimize data unit alignment checking
Date: Fri, 12 Dec 2025 17:30:38 -0800 [thread overview]
Message-ID: <20251213013038.GF2696@quark> (raw)
In-Reply-To: <20251210152343.3666103-9-hch@lst.de>
On Wed, Dec 10, 2025 at 04:23:37PM +0100, Christoph Hellwig wrote:
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 6cea8fb3e968..829ee288065a 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -326,9 +326,16 @@ int bio_split_io_at(struct bio *bio, const struct queue_limits *lim,
> struct bio_vec bv, bvprv, *bvprvp = NULL;
> unsigned nsegs = 0, bytes = 0, gaps = 0;
> struct bvec_iter iter;
> + unsigned len_align_mask = lim->dma_alignment;
> +
> + if (bio_has_crypt_ctx(bio)) {
> + struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> +
> + len_align_mask |= (bc->bc_key->crypto_cfg.data_unit_size - 1);
> + }
Needs an #ifdef CONFIG_BLK_INLINE_ENCRYPTION, since ->bi_crypt_context
is conditional on it.
>
> bio_for_each_bvec(bv, bio, iter) {
> - if (bv.bv_offset & lim->dma_alignment)
> + if (bv.bv_offset & len_align_mask)
> return -EINVAL;
As I mentioned on patch 3, I'm confused where the check of bv_len went
here. Isn't it still needed?
I think this patch is also affected by the issue I mentioned on patch 7,
where the error handling at 'out_free_bounce_pages' is not correct.
The high-level approach seems okay, though.
- Eric
next prev parent reply other threads:[~2025-12-13 1:30 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 15:23 move blk-crypto-fallback to sit above the block layer v2 Christoph Hellwig
2025-12-10 15:23 ` [PATCH 1/9] fscrypt: pass a real sector_t to fscrypt_zeroout_range_inline_crypt Christoph Hellwig
2025-12-10 15:23 ` [PATCH 2/9] fscrypt: keep multiple bios in flight in fscrypt_zeroout_range_inline_crypt Christoph Hellwig
2025-12-10 15:23 ` [PATCH 3/9] block: merge bio_split_rw_at into bio_split_io_at Christoph Hellwig
2025-12-13 0:31 ` Eric Biggers
2025-12-15 6:00 ` Christoph Hellwig
2025-12-10 15:23 ` [PATCH 4/9] blk-crypto: submit the encrypted bio in blk_crypto_fallback_bio_prep Christoph Hellwig
2025-12-13 0:48 ` Eric Biggers
2025-12-10 15:23 ` [PATCH 5/9] blk-crypto: optimize bio splitting in blk_crypto_fallback_encrypt_bio Christoph Hellwig
2025-12-13 0:56 ` Eric Biggers
2025-12-10 15:23 ` [PATCH 6/9] blk-crypto: use on-stack skcipher requests for fallback en/decryption Christoph Hellwig
2025-12-13 1:00 ` Eric Biggers
2025-12-10 15:23 ` [PATCH 7/9] blk-crypto: use mempool_alloc_bulk for encrypted bio page allocation Christoph Hellwig
2025-12-13 1:21 ` Eric Biggers
2025-12-15 6:01 ` Christoph Hellwig
2025-12-10 15:23 ` [PATCH 8/9] blk-crypto: optimize data unit alignment checking Christoph Hellwig
2025-12-11 8:28 ` kernel test robot
2025-12-11 11:43 ` kernel test robot
2025-12-13 1:30 ` Eric Biggers [this message]
2025-12-15 6:02 ` Christoph Hellwig
2025-12-16 3:16 ` kernel test robot
2025-12-10 15:23 ` [PATCH 9/9] blk-crypto: handle the fallback above the block layer Christoph Hellwig
2025-12-13 1:46 ` Eric Biggers
-- strict thread matches above, loose matches on Subject: below --
2025-12-17 6:06 move blk-crypto-fallback to sit above the block layer v3 Christoph Hellwig
2025-12-17 6:06 ` [PATCH 8/9] blk-crypto: optimize data unit alignment checking Christoph Hellwig
2025-12-19 20:14 ` Eric Biggers
2026-01-06 7:36 move blk-crypto-fallback to sit above the block layer v4 Christoph Hellwig
2026-01-06 7:36 ` [PATCH 8/9] blk-crypto: optimize data unit alignment checking Christoph Hellwig
2026-01-09 6:07 move blk-crypto-fallback to sit above the block layer v5 Christoph Hellwig
2026-01-09 6:07 ` [PATCH 8/9] blk-crypto: optimize data unit alignment checking Christoph Hellwig
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=20251213013038.GF2696@quark \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.