Thread (41 messages) 41 messages, 3 authors, 2025-11-14

Re: [PATCH 7/9] blk-crypto: handle the fallback above the block layer

From: Christoph Hellwig <hch@lst.de>
Date: 2025-11-07 12:10:32
Also in: linux-fscrypt, linux-fsdevel, linux-mm

On Thu, Nov 06, 2025 at 08:42:13PM -0800, Eric Biggers wrote:
So, the new model is that if you have a bio that might have a
bio_crypt_ctx, you always have to use blk_crypto_submit_bio() instead of
submit_bio()?
In general yes.
It looks like usually yes, but not always, because submit_bio() still
works with hardware inline encryption.
It has to, as that is the interface into the block layer that is used
by blk_crypto_submit_bio.  But the intent is that all submissions go
through blk_crypto_submit_bio first.
However, it also skips the
bio_crypt_check_alignment() check that was done before; now it happens
only in __blk_crypto_submit_bio().  So that creates an ambiguity about
whether that usage is allowed (if, hypothetically, a caller doesn't need
blk-crypto-fallback support).

Maybe the alignment check should be done both in submit_bio_noacct()
after verifying blk_crypto_config_supported_natively(), and in
__blk_crypto_submit_bio() after deciding to use the fallback?  Those
cases are exclusive, so the check would still happen just once per bio.
We could do that.  Or I lift the checking into the core bio splitting
code at least for the hardware case to reduce the overhead.  I'll see
what works out better.
Either way, the kerneldoc needs to be improved to accurately document
what blk_crypto_submit_bio() does, when it should be called, and how it
differs from submit_bio().  This also deserves a mention in the "API
presented to users of the block layer" section of
Documentation/block/inline-encryption.rst.
Ok.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help