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

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Oct 23, 2026 at 12:30:39AM +0800, Baokun Li wrote:
> Hi Eric, Thank you for your feedback!
> On 2026/10/16 02:53, Eric Biggers wrote:
> > 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?
> 
> I initially followed the LBS approach of lifting the page-size
> restriction, keeping the existing default crypto_data_unit_size
> equal to fs_block_size. I had not considered using sub-block DUs.
> 
> After your reply, I implemented a variant using min(bs, PS) for
> new default v2 policies, recording a smaller DU explicitly on disk.
> This avoids patches 3-6 and the per-bvec alignment relaxation in
> patch 10, and is indeed much simpler.
> 
> Both variants retain large-folio support and showed similar gains,
> about twice their respective 4K-block controls. Although 32K DUs reduced
> decryption calls eightfold, I did not observe a consistent additional
> throughput benefit, or CPU savings at matched bandwidth, in the tested
> workloads.
> 
> > Or do you feel that would be incomplete, and you'd indeed like to
> > support crypto_data_unit_size = fs_block_size > PAGE_SIZE?
> 
> However, keeping DU = bs has a compatibility advantage for existing
> encrypted filesystems.
> 
> For example, a 64K-block filesystem created with a default v2 policy
> on a 64K-page machine uses 64K DUs. Supporting DU > PAGE_SIZE would
> allow a 4K-page machine to use that format without re-encryption,
> assuming the other policy and backend requirements are met.
> 
> This also covers otherwise-supported legacy v1 policies, which cannot
> encode smaller DUs.
> 
> Explicit 4K v2 DUs can also be portable across page sizes, but
> choosing a smaller DU for new files does not make existing large-DU
> ciphertext readable on a smaller-page machine. I have not yet tested
> the cross-page-size migration.
> 
> If you think supporting DU = bs > PS makes this series too broad,
> I can use the simpler sub-block version in the next revision and
> develop larger-DU support separately.
> 
> Looking forward to hearing your thoughts.

I think I prefer the simpler version for now.  If someone wants to
create encrypted files on a 64K block size filesystem on a 64K PAGE_SIZE
system that are also readable on a 4K PAGE_SIZE system, for now they can
just set crypto_data_unit_size = 4K.  v1 policies were deprecated 7
years ago, so they shouldn't really factor into considerations here.

Note also that setting crypto_data_unit_size too high can break write
atomicity as well as compatibility with inline encryption hardware.

(Also, the more common use case these days is that someone is
*increasing* their page size, not decreasing it.)

I understand there's been a trend to lift limitations like these and
make every size work on every system.  But the large crypto data unit
sizes are difficult to implement correctly, and the proposed
implementation slows down common cases that matter.  Let's focus on
fs_block_size > PAGE_SIZE by itself first.

- Eric