linux-ext4 - [REGRESSION] generic/127 failure caused by "mm: Use folio_next

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20251124191811.GA26781@mac.lan>
Date: Mon, 24 Nov 2025 13:18:11 -0600
From: "Theodore Tso" <tytso@....edu>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-mm@...ck.org, Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-xfs@...r.kernel.org
Subject: [REGRESSION] generic/127 failure caused by "mm: Use folio_next_pos()"

While testing the ext4 large blocksize patches I merged in
linux-next/fs-next to pick up the mm changes needed to prevent the
warnings when allocating larger blocks with GFP_NOFAIL, and I found
some unrelated regressions with three tests, including generic/127
(the other two regressions seem unrelated to this commit; I'll bisect
them separately).

Further testing found that regression occurred somewhere between
fs-current and fs-next, and I also found that it was failing not just
for ext4, but also for ext4.  A git bisect run localized the failure
to this commit:

commit 60a70e61430b2d568bc5e96f629c5855ee159ace
Author: Matthew Wilcox (Oracle) <willy@...radead.org>
Date:   Fri Oct 24 18:08:18 2025 +0100

    mm: Use folio_next_pos()

    This is one instruction more efficient than open-coding folio_pos() +
    folio_size().  It's the equivalent of (x + y) << z rather than
    x << z + y << z.

    Signed-off-by: Matthew Wilcox (Oracle) <willy@...radead.org>
    Link: https://patch.msgid.link/20251024170822.1427218-11-willy@infradead.org

I then checked out linux-next (aka linux-next/master) and verified
that the problem was reproducible there, using

kvm-xfstests -c ext4/4k generic/127 --fail-loop-count 0 --kernel-build

And then when I reverted commit 60a70e61430b, the test passed.  I also
checked and found that this commit was also causing generic/127 to
fail for xfs:

kvm-xfstests -c xfs/4k generic/127 --fail-loop-count 0 --kernel-build

And, with the commit reverted the problem went away.

The test logs for ext4 and xfs are attached.  Willy, could you take a
look?  Many thanks!!

							- Ted

View attachment "ext4-generic-127.log" of type "text/plain" (4880 bytes)

View attachment "xfs-generic-127.log" of type "text/plain" (7314 bytes)