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

Message-ID: <9e0f5378-63d8-add4-2b79-2173a4c98086@leemhuis.info>
Date:   Sun, 18 Jun 2023 10:49:40 +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: JFYI: patches in next that might be good to mainline rather sooner
 than later?

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

And now I'm not really sure what to do with this data. :-/ :-D

Some of those commits the script found to my untrained eyes look like
something that might have been worth having in 6.4 -- especially those
with a stable-tag. But not all of them. And I'm not suggesting to merge
them. It was just a exercise to see if this might be useful.

What do you think about this? Is this helpful somehow? Or can it be made
more helpful with a few changes? Especially if someone would regularly
run this?

Ciao, Thorsten

[1]
https://gitlab.com/knurd42/kernel-scripts/-/blob/master/stats/next_stable_candidates.py
(as any code likely will contain bugs)