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.
Is there agreement that this work falls outside the scope of my patch series that fixes the write errors encountered with the combination of inline encryption and zoned storage? Thanks, Bart.
