From: Baokun Li <libaokun@linux.alibaba.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Alberto Garcia <berto@igalia.com>, Theodore Ts'o <tytso@mit.edu>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>, Ojaswin Mujoo <ojaswin@linux.ibm.com>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Zhang Yi <yi.zhang@huawei.com>,
linux-ext4@vger.kernel.org
Subject: Re: [REGRESSION] ext4: oops in ext4_finish_bio() after enabling encryption on a mounted fs
Date: Thu, 24 Sep 2026 18:19:04 +0800 [thread overview]
Message-ID: <b4660572-cbed-426c-b26e-636742aadb29@linux.alibaba.com> (raw)
In-Reply-To: <20260923180119.GA1506901@google.com>
On 2026/9/24 02:01, Eric Biggers wrote:
> On Wed, Sep 23, 2026 at 09:28:54PM +0800, Baokun Li wrote:
>> On 2026/9/23 20:40, Alberto Garcia wrote:
>>> On Wed, Sep 23, 2026 at 08:12:03PM +0800, Baokun Li wrote:
>>>>> 1) Enable encryption on an ext4 filesystem with tune2fs -O encrypt
>>>> Is it valid to enable encrypt at mount time?
>>> Good question, I always understood that it was allowed and tune2fs
>>> certainly doesn't forbid it (compare with casefold):
>>>
>>> https://github.com/tytso/e2fsprogs/blob/v1.47.4/misc/tune2fs.c#L1599
>>>
>>> Berto
>>
>> If enabling encryption on a mounted ext4 fs is allowed,
>> I think the current change is fine.
>>
>> Ted, Eric - would either of you know the details here?
> Yes, it is allowed.
>
> The proposed patch looks good, even though the problem seems to be gone
> on mainline already due to the removal of the code path that used the
> non-large-folio-compatible function fscrypt_encrypt_pagecache_blocks().
Agreed, then this current modification can be made into a separate
bugfix for backporting to stable.
>
> There can be another patch that removes both that check and the
> mount-time check, if they're truly no longer needed (I don't know of any
> reason why they would be, but it needs to be properly tested).
After removing both checks, I ran
kvm-xfstests -c ext4/32k -g encrypt
16 of the 29 tests still fail. blk-crypto-fallback still en/decrypts one
page at a time, while the data unit size is 32k with a block size larger
than the page size. It doesn't crash, but the writes fail with
BLK_STS_INVAL, so write() succeeds while the data never reaches the disk,
and reads fail once the page cache is dropped.
Supporting data units larger than a page is simple enough. A rough
implementation of mine already gives 30%~50% higher buffered I/O
throughput with 32k blocks than with 4k blocks. The patches are still
being polished, and I'll send them out in the next two days.
Thanks,
Baokun
next prev parent reply other threads:[~2026-09-24 10:19 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 11:12 [REGRESSION] ext4: oops in ext4_finish_bio() after enabling encryption on a mounted fs Alberto Garcia
2026-09-23 11:43 ` sashiko-bot
2026-09-23 12:12 ` Baokun Li
2026-09-23 12:40 ` Alberto Garcia
2026-09-23 13:28 ` Baokun Li
2026-09-23 18:01 ` Eric Biggers
2026-09-24 10:19 ` Baokun Li [this message]
2026-09-24 15:15 ` Alberto Garcia
2026-09-24 18:04 ` Eric Biggers
2026-09-25 11:06 ` Alberto Garcia
2026-09-25 19:07 ` Eric Biggers
2026-09-27 22:12 ` Alberto Garcia
2026-09-29 11:18 ` Jan Kara
2026-09-23 13:29 ` Jan Kara
2026-09-23 13:39 ` Alberto Garcia
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=b4660572-cbed-426c-b26e-636742aadb29@linux.alibaba.com \
--to=libaokun@linux.alibaba.com \
--cc=adilger.kernel@dilger.ca \
--cc=berto@igalia.com \
--cc=ebiggers@kernel.org \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox