linux-ext4 - Re: [PATCH v2 00/24] ext4: enable block size larger than page size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c244379f-71c8-4ce7-af87-1bfa6507af28@huawei.com>
Date: Thu, 13 Nov 2025 17:14:52 +0800
From: Baokun Li <libaokun1@...wei.com>
To: Theodore Ts'o <tytso@....edu>
CC: <linux-ext4@...r.kernel.org>, <adilger.kernel@...ger.ca>, <jack@...e.cz>,
	<linux-kernel@...r.kernel.org>, <kernel@...kajraghav.com>,
	<mcgrof@...nel.org>, <ebiggers@...nel.org>, <willy@...radead.org>,
	<yi.zhang@...wei.com>, <yangerkun@...wei.com>, <chengzhihao1@...wei.com>,
	Baokun Li <libaokun@...weicloud.com>, "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [PATCH v2 00/24] ext4: enable block size larger than page size

On 2025-11-12 23:29, Theodore Ts'o wrote:
> On Wed, Nov 12, 2025 at 02:27:19PM +0800, Baokun Li wrote:
>> Darrick’s reply in another thread has already made a similar change,
>> so we can apply that patch first for testing.
> I'll give that a try when I have a chance.  For now, here's a test run
> using a version of my test appliance which excludes the way group for
> the config ext4/lbs, and which has a modified e2fsprogs (built from
> the latest e2fsprogs git repo) which suppresses both warnings when
> using large block sizes if the kernel has the blocksize_gt_pagesize
> feature detected.
>
> ext4/lbs: 595 tests, 6 failures, 101 skipped, 6656 seconds
>   Failures: ext4/033 generic/620 generic/759 generic/760
>   Flaky: generic/251: 60% (3/5)   generic/645: 40% (2/5)
> Totals: 619 tests, 101 skipped, 25 failures, 0 errors, 6291s
>
> Fixing all of these filures is not a blocker for getting this patchset
> upstream, but it would be nice for us to figure out the root cause for
> them, so we can decide whether it's better to exclude the tests for
> now, or whether there's an easy fix.

Thank you for your testing! I have analyzed the above failing cases, and
they are basically unrelated to this patch set. My analysis is as follows:

# generic/759 generic/760
Require CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS enabled.

# generic/620
vdc needs at least 33G. Passed after replacing with a 2T disk. Suggest
putting this test case into exclude.

# ext4/033
1. With 64k block size, inodes_per_group=$((blksz*8)) does not hold;
2. Creating a 400+T snapshot and formatting it as a 64k ext4 filesystem
    requires more than 1T of disk space just for metadata;
3. With 64k block size ext4, when orphan file is enabled by default,
    it fails because orphan file size exceeds 8 << 20. Fixed in [1].
    [1]:
https://lore.kernel.org/r/20251113090122.2385797-1-libaokun@huaweicloud.com
After resolving the above issues, the test passes with a 2T disk. However,
since the inode number overflow is unrelated to block size, suggest putting
this test case into exclude.

# generic/645
This test checks that idmapped mounts behave correctly with complex user
namespaces. On my side the reproduction rate is very low, about 1/100.
Even before the code was merged, occasional failures also appeared in the
4k tests. Based on the test content, I think it is unrelated to LBS.

Cheers,
Baokun