linux-kernel - Re: linux-next: manual merge of the mm-stable tree with the ext4 tree

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: <Y/k4Jvph15ugcY54@mit.edu>
Date:   Fri, 24 Feb 2023 17:20:22 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        "Vishal Moola (Oracle)" <vishal.moola@...il.com>
Subject: Re: linux-next: manual merge of the mm-stable tree with the ext4 tree

Sorry for the delay in taking a look at things; this week has been
horribly crazy busy for me.

The conflict is with the folio changes in mm-stable and with Jan's
"ext4: Cleanup data=journal writeback path" patch series.  Both of
these touch mpage_prepare_extent_to_map() in fs/ext4/inode.c quite
extensively.

[1] https://lore.kernel.org/r/20230111152736.9608-1-jack@suse.cz

I've just tried taking Jan's patch series and applying it linux-next
(which contains the mm-stable branch).  Dealing with each chage one by
one, there were conflits with patches #1, #4, #5, and #7.  One at the
time, the conflict resolutions weren't _that_ bad, but looking at the
combined conflict after doing a "git merge" it was quite scary indeed.

Maybe Linus's git merging-fu is much stronger than mine, but I
certainly wouldn't wnat to try to resolve it just using "git merge"!

So here's my proposed path forawrd.

1)  So far the only testing Jan's patch series (modified so it sits on
top of linux-next) is "it builds, ship it".  So I'll kick off a full
xfstests test on that series, and make sure I don't see any
regressions.  After that, I'll post it on linux-ext4 for Jan to
examine.

(Since it's well after work hours in Europe on a Friday, Jan probably
won't get to it until Monday, which is fine.)

2) I'll drop Jan's patch set from the ext4 dev branch, and run the
following full xfstests runs on this dev "lite" branch.  (a) the dev
"lite" branch by itself.  (b) the dev "lite" branch merged with tip of
Linux's tree.  (c) the dev "lite" branch merged with linux-next.

99.9% of the time, when there are problems, they are detected by my
full set of xfstests regression testing, since random users running
linux-next tend not stress file system all that much, and the 0-day
bot doesn't do nearly as much testing as I do.  (I test a dozen
different ext4 fs configs[2], while the 0-day tests only a single
one.)

[2] https://github.com/tytso/xfstests-bld/blob/master/test-appliance/files/root/fs/ext4/cfg/all.list

3)  I'll then send the ext4 dev branch (minus the data=writepage
cleanups) as a pull request to Linus.  Next week, after Jan has a
chance to review my patch conflict resolutions, I'll send a second
pull request with the data=writepage cleanups.  (As usual, I'll do my
full set of test runs before sending the pull request.)

Linus, are you OK with this plan?

						- Ted