On Tue, Jul 15, 2025 at 01:10:48PM -0700, Bart Van Assche wrote: > Changes compared to v2: > - Added a patch that optimizes blk_crypto_max_io_size(). > - Added three patches that change calling conventions in the crypto fallback > code. > - Added a patch to remove crypto_bio_split. > - Moved the blk_crypto_max_io_size() call into get_max_io_size(). But this doesn't address the issue we're discussing where this patchset makes data be silently left unencrypted on some block devices. If it's really only a "few random drivers that almost no one cares about", then it's possible we can drop the blk-crypto-fallback support for them anyway, as Christoph is suggesting. However, it needs to be done safely. That means at least making blk_crypto_config_supported() continue to return false when called on a block_device that doesn't support any form of blk-crypto (either native or fallback), and likewise making blk_crypto_start_using_key() continue to return an error. Ideally, the actual I/O would also continue to fail if it's attempted anyway. Overall, it's a bit frustrating seeing these patches go by that propose to silently leave data unencrypted when upper layers requested that it be encrypted. IMO this is actually a point against handling encryption in the block layer... The whole point of storage encryption (whether fscrypt, dm-crypt, dm-inlinecrypt, or something else) is that the data is actually encrypted. But if the actual encryption is done using code whose developers / maintainers don't really consider encryption to be a priority, that's not a great place to be. - Eric
