All of lore.kernel.org
 help / color / mirror / Atom feed
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 9/9] blk-crypto: handle the fallback above the block layer
Date: Fri, 12 Dec 2025 17:46:43 -0800	[thread overview]
Message-ID: <20251213014643.GG2696@quark> (raw)
In-Reply-To: <20251210152343.3666103-10-hch@lst.de>

On Wed, Dec 10, 2025 at 04:23:38PM +0100, Christoph Hellwig wrote:
> +To submit a bio that uses inline encryption, users must call
> +``blk_crypto_submit_bio()`` instead of the usual ``submit_bio()``.  This will
> +submit the bio to the underlying driver if it supports inline crypto, or else
> +call the blk-crypto fallback routines before submitting normal bios to the
> +underlying drivers.

Maybe worth mentioning that submit_bio() still works if
blk-crypto-fallback support isn't needed?  I think device-mapper relies
on that when using targets with DM_TARGET_PASSES_CRYPTO on block devices
with hardware inline encryption support.  The original submitter uses
blk_crypto_submit_bio(), but the device-mapper layer doesn't, which is
okay because the fallback (if needed) would have been done already.

> +/**
> + * blk_crypto_submit_bio - Submit a bio using inline encryption

"bio using inline encryption" => "bio that may have a crypto context"
(or "bio that may be using inline encryption")

> + * @bio: bio to submit
> + *
> + * If @bio has not crypto context, or the crypt context attached to @bio is

not => no

Besides these documentation issues it looks okay though.

Reviewed-by: Eric Biggers <ebiggers@kernel.org>

- Eric

  reply	other threads:[~2025-12-13  1:46 UTC|newest]

Thread overview: 26+ 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
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 [this message]
  -- 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 9/9] blk-crypto: handle the fallback above the block layer Christoph Hellwig
2026-01-06  7:36 move blk-crypto-fallback to sit above the block layer v4 Christoph Hellwig
2026-01-06  7:36 ` [PATCH 9/9] blk-crypto: handle the fallback above the block layer 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 9/9] blk-crypto: handle the fallback above the block layer 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=20251213014643.GG2696@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.