All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Baokun Li" <libaokun@linux.alibaba.com>
Cc: linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org, tytso@mit.edu
Subject: Re: [PATCH 11/13] ext4: allow encryption with a block size larger than the page size
Date: Sun, 11 Oct 2026 17:30:19 +0000	[thread overview]
Message-ID: <sashiko-outbox-167351@kernel.org> (raw)
In-Reply-To: <20261011170958.1759230-12-libaokun@linux.alibaba.com>

> ext4 refuses encryption when the block size is larger than the page
> size, both at mount time and on a mounted filesystem, and refuses to
> load an existing encrypted inode.  The checks exist because such a
> block size needs folios that cover a whole block, while file contents
> were encrypted page by page in the fs-layer path, which cannot handle a
> folio that covers several data units.
> 
> Since commit 5acc6f649a68 ("fscrypt: Always use blk-crypto for contents
> on block-based filesystems") file contents are always encrypted through
> blk-crypto, and after the adaptations in the preceding patches, both
> inline encryption hardware and blk-crypto-fallback support data units
> larger than a page, so the checks can be removed.
> 
> Encrypted filesystems still keep their folio order at s_min_folio_order;
> allowing large folios needs additional work and will be enabled later.
> 
> Performance:
> 
> 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.
> 
>   job          4k plain      4k enc    32k plain    32k enc    4k->32k
>   ---------    --------    --------    ---------    -------    -------
>   seqwrite         1981        1044         2062       1399       +34%
>   seqread          1139         931         1791       1793       +93%
> 
> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261011170958.1759230-1-libaokun@linux.alibaba.com?part=11


  reply	other threads:[~2026-10-11 17:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 17:09 [PATCH 00/13] block, ext4: allow encryption with a block size larger than the page size Baokun Li
2026-10-11 17:09 ` [PATCH 01/13] ext4: refuse encryption when block size > " Baokun Li
2026-10-11 17:26   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 02/13] ext4: reject encrypted inodes " Baokun Li
2026-10-11 17:16   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 03/13] blk-crypto: reject fallback data unit sizes it can't handle Baokun Li
2026-10-11 17:20   ` sashiko-bot
2026-10-12  7:50     ` Baokun Li
2026-10-11 17:09 ` [PATCH 04/13] blk-crypto: decrypt one data unit per crypto request Baokun Li
2026-10-11 17:19   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 05/13] blk-crypto: encrypt " Baokun Li
2026-10-11 17:26   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 06/13] blk-crypto: support data units larger than a page Baokun Li
2026-10-11 17:27   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 07/13] iomap: align the direct I/O bios of encrypted files to the block size Baokun Li
2026-10-11 17:25   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 08/13] block: split encrypted bios at data unit boundaries Baokun Li
2026-10-11 17:20   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 09/13] block: warn about bios that can't be split Baokun Li
2026-10-11 17:18   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 10/13] block: don't require data unit aligned bio_vecs for encrypted bios Baokun Li
2026-10-11 17:24   ` sashiko-bot
2026-10-12  8:09     ` Baokun Li
2026-10-11 17:09 ` [PATCH 11/13] ext4: allow encryption with a block size larger than the page size Baokun Li
2026-10-11 17:30   ` sashiko-bot [this message]
2026-10-11 17:09 ` [PATCH 12/13] ext4: send folios that cover a wraparound to the buffer_head path Baokun Li
2026-10-11 17:22   ` sashiko-bot
2026-10-11 17:09 ` [PATCH 13/13] ext4: allow large folios for encrypted files Baokun Li
2026-10-11 17:23   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-167351@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.