#regzbot introduced: 8147c4c4546f9f05ef03bb839b741473b28bb560 ^ OK, I've isolated the regression of generic/455 failing with ext4/1k to this commit, which came in via the mm tree. Nothing seems *obviously* wrong, but I'm not sure if there are any differences in the semantics of the new folio functions such as kmap_local_folio, offset_in_folio, set_folio_bh() which might be making a difference. Using kvm-xfstests[1] I bisected this via the command: % install-kconfig ; kbuild ; kvm-xfstests -c ext4/1k -C 10 generic/455 [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md And the bisection pointed me at this commit: commit 8147c4c4546f9f05ef03bb839b741473b28bb560 (refs/bisect/bad) Author: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> AuthorDate: Thu Jul 13 04:55:11 2023 +0100 Commit: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> CommitDate: Fri Aug 18 10:12:30 2023 -0700 jbd2: use a folio in jbd2_journal_write_metadata_buffer() During the bisection, I treated a commit with 3+ failures as "bad", and 0-2 commits as "good". Running generic/455 50 times to get a sense of the failure, with the first bad commit (8147c4c4546f), I got: ext4/1k: 50 tests, 21 failures, 223 seconds Flaky: generic/455: 42% (21/50) Totals: 50 tests, 0 skipped, 21 failures, 0 errors, 223s While with the immediately preceding commit (07811230c3cd), I got: ext4/1k: 50 tests, 4 failures, 235 seconds Flaky: generic/455: 8% (4/50) Totals: 50 tests, 0 skipped, 4 failures, 0 errors, 235s Comparing these two commits (8147c4c4546f vs 07811230c3cd) using the ext4 with a 4k block size, I get: ext4/4k: 50 tests, 2 failures, 365 seconds Flaky: generic/455: 4% (2/50) Totals: 50 tests, 0 skipped, 2 failures, 0 errors, 365s vs ext4/4k: 50 tests, 2 failures, 349 seconds Flaky: generic/455: 4% (2/50) Totals: 50 tests, 0 skipped, 2 failures, 0 errors, 349s So issue seems to be specifically with a sub-page size block size, since ext4/4k doesn't show any issues, while ext4/1k does. - Ted
