Re: [PATCH 00/13] block, ext4: allow encryption with a block size larger than the page size

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Oct 12, 2026 at 01:09:45AM +0800, Baokun Li wrote:
> Motivation
> ==========
> 
> ext4 supports a block size larger than the page size (LBS), e.g. a 32k
> block size on a machine with 4k pages [1].  Encryption, however, is
> still refused on such a filesystem: file contents used to be encrypted
> page by page in the fs-layer path, which cannot handle a folio that
> covers several data units, so the checks that refuse encryption with
> such a block size stayed in place.
> 
> Since commit 5acc6f649a68 ("fscrypt: Always use blk-crypto for
> contents on block-based filesystems") file contents are always
> encrypted through blk-crypto.  Inline encryption hardware can already
> en/decrypt a data unit that spans several pages, but the fallback and
> the block layer cannot carry such a data unit:
> 
>   1. blk-crypto-fallback en/decrypts a data unit with the bio_vecs of
>      a single page-clamped segment, so a larger data unit fails with
>      BLK_STS_INVAL;
>   2. the block layer requires every bio_vec of an encrypted bio to be
>      data unit aligned, and splits such a bio without rounding the
>      split size down to the data unit size;
>   3. iomap cuts the direct I/O bios of an encrypted file only at the
>      logical block size of the device, so a bio can end in the middle
>      of a data unit.
> 
> This series adds the missing pieces on all three layers, removes the
> refusals, and enables large folios for encrypted files on the way.
> 
> [1]: https://lore.kernel.org/all/20251121090654.631996-1-libaokun@huaweicloud.com

A high-level question: most of the complexity in this series is to
support crypto_data_unit_size > PAGE_SIZE, despite the actual goal being
to support fs_block_size > PAGE_SIZE.  It's left unstated that the
default of crypto_data_unit_size == fs_block_size is used.  However,
ext4 and f2fs already support crypto_data_unit_size < fs_block_size.

Would leaving the crypto_data_unit_size at e.g. 4 KiB while increasing
fs_block_size be a simpler way to achieve the goal of this series?

Or do you feel that would be incomplete, and you'd indeed like to
support crypto_data_unit_size = fs_block_size > PAGE_SIZE?

- Eric