[PATCH 0/4] ext4: support encryption with block size larger than page size

[Baokun Li <libaokun@linux.alibaba.com>]

Motivation
==========

Currently ext4 refuses encryption on a filesystem whose block size
is larger than page size.  The reason is in the fallback path:
fscrypt takes the fs block size as the default data  unit size,
while blk-crypto-fallback supports no data unit larger than a page.

fscrypt already supports a data unit size smaller than the block size.
So when none is specified, taking the smaller of the block size and the
page size as the data unit size is enough for fscrypt to support LBS.

Based on v7.4-rc1.

Patch Overview
==============

Patch 1: Caps the default data unit at the page size and rejects the
         policies that would exceed it.
Patch 2: Validates the test_dummy_encryption policy before applying it.
Patch 3: Sends a folio that covers a DUN wraparound to the buffer_head
         path.
Patch 4: Removes the block size > page size checks and enables large
         folios for encrypted files.

Testing
=======

kvm-xfstests -c ext4/all -g auto has been executed with no new failures.

On ext4/32k, two groups of tests fail because they are not adapted, and
no other regressions were observed:

 - the tests that use v1 policies: ext4/024, generic/395, 397, 398, 399,
   419, 421, 429, 440, 576, 580, 581, 593, 613.
 - the tests that don't explicitly set the data unit size (generic/582,
   583, 584): the kernel gets a 4K data unit by default on a 4K-page
   machine while the tests still use the block size.

With the xfstests fix, the first group is skipped and the second group
passes.  The fix will be sent separately.

Benchmark
=========

Hardware: 96-core machine, 3.84T NVMe, 512G memory
Filesystem: ext4, encryption on the fallback path

Buffered sequential 1M writes and reads (1G, fsync) in MiB/s;
medians of 3 runs.

Base tree, 4k-block filesystem:

  job         4k plain    4k enc
  --------    --------    ------
  seqwrite        1969      1418
  seqread         1021       907

LBS enabled, encrypted 4k-block vs 32k-block filesystem:

  job         4k enc    32k enc    32k plain    4k->32k
  --------    ------    -------    ---------    -------
  seqwrite      1430       1958         2138       +37%
  seqread        964       2004         1834      +108%

Buffered sequential writes (1G, fsync) of the encrypted 4k-block
filesystem across request sizes, base tree vs this series:

  fio bs    Before    After    gain
  ------    ------    -----    ----
  4k        1272      1261     -1%
  16k       1457      1803    +24%
  64k       1499      2060    +37%
  256k      1488      2103    +41%
  1M        1418      1928    +36%

Comments and questions are, as always, welcome.

Thanks,
Baokun

Baokun Li (4):
  fscrypt: Cap data units at the page size
  fscrypt: Validate the test_dummy_encryption policy for new inodes
  ext4: don't put a DUN wraparound in the middle of a read bio
  ext4: allow large folios and bs > ps encryption

 Documentation/filesystems/fscrypt.rst | 19 +++++++++++++++----
 fs/crypto/fscrypt_private.h           |  4 +++-
 fs/crypto/keysetup.c                  |  8 ++++++++
 fs/crypto/policy.c                    | 11 ++++++++++-
 fs/ext4/crypto.c                      |  9 ---------
 fs/ext4/inode.c                       |  6 ------
 fs/ext4/readpage.c                    | 10 ++++++++++
 fs/ext4/super.c                       | 22 +---------------------
 8 files changed, 47 insertions(+), 42 deletions(-)

-- 
2.43.7