From: Eric Biggers <ebiggers@kernel.org>
To: Baokun Li <libaokun@linux.alibaba.com>
Cc: linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-xfs@vger.kernel.org, jaegeuk@kernel.org, axboe@kernel.dk,
hch@lst.de, djwong@kernel.org, brauner@kernel.org, tytso@mit.edu,
berto@igalia.com, adilger.kernel@dilger.ca, jack@suse.cz,
yi.zhang@huawei.com, ojaswin@linux.ibm.com,
ritesh.list@gmail.com, stable@vger.kernel.org
Subject: Re: [PATCH 03/13] blk-crypto: reject fallback data unit sizes it can't handle
Date: Thu, 15 Oct 2026 18:45:19 +0000 [thread overview]
Message-ID: <20261015184519.GF2170687@google.com> (raw)
In-Reply-To: <20261011170958.1759230-4-libaokun@linux.alibaba.com>
On Mon, Oct 12, 2026 at 01:09:48AM +0800, Baokun Li wrote:
> Such keys exist on filesystems whose
> block size is larger than the page size, because fscrypt uses the block
> size as its data unit size by default.
>
> Fix this by advertising only the data unit sizes that the fallback
> really supports, and by rejecting keys that the fallback can't handle in
> blk_crypto_fallback_start_using_key(), so that the failure happens when
> the key is set up instead of during I/O, and before any data is written.
>
> Fixes: 488f6682c832 ("block: blk-crypto-fallback for Inline Encryption")
> Cc: stable@vger.kernel.org
> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Several patches in this series are marked as fixes, but they seem to
only be needed for encryption with data_unit_size > PAGE_SIZE which is a
new feature in this series. I don't think these should be marked as
fixes, as they will cause unnecessary backports, CVEs, etc.
- Eric
next prev parent reply other threads:[~2026-10-15 18:45 UTC|newest]
Thread overview: 31+ 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-15 18:45 ` Eric Biggers [this message]
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
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
2026-10-15 18:53 ` [PATCH 00/13] block, ext4: allow encryption with a block size larger than the page size Eric Biggers
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=20261015184519.GF2170687@google.com \
--to=ebiggers@kernel.org \
--cc=adilger.kernel@dilger.ca \
--cc=axboe@kernel.dk \
--cc=berto@igalia.com \
--cc=brauner@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jaegeuk@kernel.org \
--cc=libaokun@linux.alibaba.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=yi.zhang@huawei.com \
/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.