Re: [PATCH v3 0/7] Fix bio splitting by the crypto fallback code

[Eric Biggers <ebiggers@kernel.org>]

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