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.
