linux-ext4 - Re: [fstests generic/388, 455, 475, 482 ...] Ext4 journal recovery test fails

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230904060819.GB701295@mit.edu>
Date:   Mon, 4 Sep 2023 02:08:19 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Zorro Lang <zlang@...nel.org>
Cc:     linux-ext4@...r.kernel.org, fstests@...r.kernel.org,
        regressions@...ts.linux.dev, Matthew Wilcox <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [fstests generic/388, 455, 475, 482 ...] Ext4 journal recovery
 test fails

#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@...radead.org>
    AuthorDate: Thu Jul 13 04:55:11 2023 +0100
    Commit: Andrew Morton <akpm@...ux-foundation.org>
    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