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@infradead.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@infradead.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