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 7/9] blk-crypto: use mempool_alloc_bulk for encrypted bio page allocation
Date: Fri, 12 Dec 2025 17:21:41 -0800 [thread overview]
Message-ID: <20251213012141.GE2696@quark> (raw)
In-Reply-To: <20251210152343.3666103-8-hch@lst.de>
On Wed, Dec 10, 2025 at 04:23:36PM +0100, Christoph Hellwig wrote:
> Calling mempool_alloc in a lot is not safe unless the maximum allocation
lot => loop
> + /*
> + * Try a bulk allocation first. This could leave random pages in the
> + * array unallocated, but we'll fix that up later in mempool_alloc_bulk.
> + *
> + * Note: alloc_pages_bulk needs the array to be zeroed, as it assumes
> + * any non-zero slot already contains a valid allocation.
> + */
> + memset(pages, 0, sizeof(struct page *) * nr_segs);
> + nr_allocated = alloc_pages_bulk(GFP_KERNEL, nr_segs, pages);
> + if (nr_allocated < nr_segs)
> + mempool_alloc_bulk(blk_crypto_bounce_page_pool, (void **)pages,
> + nr_segs, nr_allocated);
alloc_pages_bulk() is documented to fill in pages sequentially. So the
"random pages in the array unallocated" part seems misleading. This
also means that only the remaining portion needs to be passed to
mempool_alloc_bulk(), similar to blk_crypto_fallback_encrypt_endio().
> @@ -210,6 +249,7 @@ static void __blk_crypto_fallback_encrypt_bio(struct bio *src_bio,
> u64 curr_dun[BLK_CRYPTO_DUN_ARRAY_SIZE];
> struct scatterlist src, dst;
> union blk_crypto_iv iv;
> + struct page **enc_pages;
> unsigned int enc_idx;
> struct bio *enc_bio;
> unsigned int j;
> @@ -227,15 +267,13 @@ static void __blk_crypto_fallback_encrypt_bio(struct bio *src_bio,
>
> /* Encrypt each page in the source bio */
> new_bio:
> - enc_bio = blk_crypto_alloc_enc_bio(src_bio, nr_segs);
> + enc_bio = blk_crypto_alloc_enc_bio(src_bio, nr_segs, &enc_pages);
> enc_idx = 0;
> for (;;) {
> struct bio_vec src_bv =
> bio_iter_iovec(src_bio, src_bio->bi_iter);
> - struct page *enc_page;
> + struct page *enc_page = enc_pages[enc_idx];
>
> - enc_page = mempool_alloc(blk_crypto_bounce_page_pool,
> - GFP_NOIO);
> __bio_add_page(enc_bio, enc_page, src_bv.bv_len,
> src_bv.bv_offset);
[...]
> out_free_bounce_pages:
> enc_idx++;
> while (enc_idx > 0)
> mempool_free(enc_bio->bi_io_vec[--enc_idx].bv_page,
> blk_crypto_bounce_page_pool);
> bio_put(enc_bio);
This error handling path looks incorrect after this change. It needs to
free all the pages, not just the ones used so far.
Otherwise this looks good, thanks.
- Eric
next prev parent reply other threads:[~2025-12-13 1:21 UTC|newest]
Thread overview: 28+ 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 [this message]
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
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 7/9] blk-crypto: use mempool_alloc_bulk for encrypted bio page allocation Christoph Hellwig
2025-12-19 20:02 ` Eric Biggers
2025-12-19 20:25 ` Eric Biggers
2025-12-22 22:16 ` Christoph Hellwig
2025-12-22 22:18 ` 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=20251213012141.GE2696@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 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).