linux-kernel - Re: JFYI: patches in next that might be good to mainline rather sooner than later?

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: <24edd13e-791a-bd05-0a44-dd5475c7e200@leemhuis.info>
Date:   Sun, 18 Jun 2023 15:40:15 +0200
From:   Thorsten Leemhuis <linux@...mhuis.info>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     Linux kernel regressions list <regressions@...ts.linux.dev>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: JFYI: patches in next that might be good to mainline rather
 sooner than later?

On 18.06.23 10:49, Thorsten Leemhuis wrote:
> Hi Linus, hi Greg,
> 
> I got the impression that early stable releases with a huge number of
> patches (like 6.3.2 with ~690 changes) seems to cause a few regressions.
> As you know, those releases usually contain many backports of changes
> merged during the merge window for the following mainline release (e.g.
> 6.4). That made me wonder:
> 
> How many patches do we have in linux-next right now that better should
> be merged this cycle (e.g. ahead of the 6.4 release) instead of merging
> them in the merge window for 6.5 and backporting them shortly afterwards?
> 
> To check I briefly set down and quickly hacked together a python
> script[1] that looks at linux-next for patches with tags like 'Cc:
> stable...' and 'Fixes: ', as all respectively some (or many?) of those
> will be backported. I made the script ignore a few things, like commits
> from the past eight days and commits that fix changes committed to
> mainline more that a year ago.
> 
> I ran this a few minutes ago and it spilled out about 260 changes (about
> 80 of them with a stable tag). I put the results into a table:
> https://docs.google.com/spreadsheets/d/1OnMrde1e7LBMPhOPJL0Sn9rd3W32mTGls_qGMoZS8z8/edit?usp=sharing

TWIMC, I just updated the data slightly, as I updated the script to also
look for commits that revert changes from the current mainline cycle.

Did that while I was preparing this weeks regression report and noticed
a series of reverts[1] in next where my brain said "hmmm, Andrew merged
those more than a week ago to mm-hotfixes-unstable and -rc7 is due
today; I don't see a pr from him and wonder if these revert are
something that better should be in rc7 to help preventing a rc8?"

[1] https://lore.kernel.org/all/20230609081518.3039120-1-qi.zheng@linux.dev/
noticed it via
https://lore.kernel.org/lkml/ZH6K0McWBeCjaf16@dread.disaster.area/

BTW, quick reminder for the data in the spreadsheet, to ensure nobody
gets this wrong:

> [...] And I'm not suggesting to merge them [to mainline].
> It was just a exercise to see if this might be useful.

IOW: the spreadsheet definitely mentioned commits in next that
definitely are not suited for this merge window.

Ciao, Thorsten