On 7/16/25 9:43 PM, Christoph Hellwig wrote:
Getting back to this. While the ton is a bit snarky, it brings up a good point. Relying on the block layer to ensure that data is always encrypted seems like a bad idea, given that is really not what the block layer is about, and definitively not high on the mind of anyone touching the code. So I would not want to rely on the block layer developers to ensure that data is encrypted properly through APIs not one believes part that mission. So I think you'd indeed be much better off not handling the (non-inline) incryption in the block layer. Doing that in fact sounds pretty easy - instead of calling the blk-crypto-fallback code from inside the block layer, call it from the callers instead of submit_bio when inline encryption is not actually supported, e.g. if (!blk_crypto_config_supported(bdev, &crypto_cfg)) blk_crypto_fallback_submit_bio(bio); else submit_bio(bio); combined with checks in the low-level block code that we never get a crypto context into the low-level submission into ->submit_bio or ->queue_rq when not supported. That approach not only is much easier to verify for correct encryption operation, but also makes things like bio splitting and the required memory allocation for it less fragile.
Has it ever been considered to merge the inline encryption code into dm-crypt or convert the inline encryption fallback code into a new dm driver? If user space code would insert a dm device between filesystems and block devices if hardware encryption is not supported that would have the following advantages: * No filesystem implementations would have to be modified. * It would make it easier to deal with bio splitting since dm drivers can set stacking limits in their .io_hints() callback. Thanks, Bart.
