Re: Finding mm patches to review before those are pulled into the mainline (was "Re: [PATCH v2] fix AMDGPU failure with periodic signal")

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Wed, Jan 07, 2026 at 10:26:35PM -0800, SeongJae Park wrote:
> On Tue, 6 Jan 2026 21:52:25 +0000 Pedro Falcato <pfalcato@suse.de> wrote:
>
> [...]
> > I understand your point. I don't think anyone wants to see patches falling
> > through the cracks. But we also don't want patches to get applied without
> > any review.
>
> I can also clearly see both Andrew and Lorenzo are trying their best to make
> Linux kernel better with only good faiths.  I always appreciate their such
> efforts.  And both their opinions make sense to me in their ways.

I mean, sorry but what? This makes me think you haven't understood what's
happened here.

This patch would have been merged _without any review whatsoever_ given the
circumstances (no M/R cc'd, the original email not replied to and from 2 months
ago).

I don't understand how we can be both-sides-ing here - treating merging stuff to
mainline without review for the _core_ infrastructure of the kernel as a bug
tracker is simply crazy.

Anything that involves merging stuff to mainline simpy to track it is
insane. This is core infrastructure, we shouldn't be breaking mainline in order
to track stuff.

Yet again the whole thing is set up in such a way that reviewers have to jump on
things, rather than submitters having to - gasp - wait sometimes.

>
> >
> > Perhaps it's time to deploy something like Patchwork to help track
> > outstanding patches?

I mean they're not outstanding, they get merged. So I'm not sure how you'd track
stuff that way?

All of this is predicated on Andrew no longer merging things without
review. Otherwise it's moot.

>
> Nooo...  I'm too dumb and lazy to learn how to use Patchwork...
>
> I believe we always have rooms to improve, though.  One way to resolve concerns
> raised here would be asking Andrew, someone, or some tools pinging relevant
> reviewers of patches that Andrew wants to add to mm tree.  But I think that
> might be too much request for a signle human, especially for mm, which is a
> huge subsystem that many reviewers exist.  And because the reviewers have their
> own tastes, the solution may not fit very well to all the reviewers.  For
> example, someone might dislike directly getting such notification mails in
> their inbox.

I mean no, please - each individual sub-maintainer might have series they're
well aware of not being reviewed yet.

And again, any kind of tracking is really not meaningful if we just merge stuff
anyway.

>
> In the past, I actually considered making and running a tool that scans patch
> mails that not Cc-ing relevant reviewers based on get_maintainers.pl and
> forward those to the missing reviewers.  But I didn't make it because I worried
> polluting someone's inbox.  I should also confess I worried my electricity bill
> :)
>
> As an alternative way, I was wondering what if reviewers consider mm tree as a
> kind of compacted and curated version of the mailing list.  That is, using the
> mm tree as the useful place that we can more easily find patches that we need
> to review asap.  If it turns out there is no time to review immediately, the
> reviewer can always ask Andrew to wait.
>
> Finding such patches from mm tree may be much easier than doing that from the
> mailing list, since the number of patches to look for is much smaller, and
> writing scripts for that would be much easier, since we can use our favorite
> tool, git.  For example, I just wrote below simple script to find such patches
> for DAMON from mm tree:
>
>
> '''
> #!/bin/bash
>
> if [ $# -ne 1 ]
> then
>         echo "Usage: $0 <commits>"
>         exit 1
> fi
>
> commits=$1
>
> review_missed=""
>
> for commit in $(git log --reverse "$commits" --pretty=%H)
> do
>         commit_content=$(git show "$commit")
>         if ! echo "$commit_content" | grep damon --quiet
>         then
>                 continue
>         fi
>         if echo "$commit_content" | grep "Signed-off-by: SeongJae Park" --quiet
>         then
>                 continue
>         fi
>         if ! git show "$commit" | grep "Reviewed-by: SeongJae Park" --quiet
>         then
>                 review_missed+="$commit "
>         fi
> done
>
> for commit in $review_missed
> do
>         desc=$(git log -1 "$commit" --pretty="%h (\"%s\")")
>         echo "review missed for $desc"
> done
> '''
>
> And it indeed found some interesting patches for me:
>
> '''
> $ bash commits_to_review.sh mm-stable..mm-new
> review missed for cb844296e68a ("mm: introduce CONFIG_ARCH_HAS_LAZY_MMU_MODE")
> review missed for 7bc3a776d611 ("mm: add basic tests for lazy_mmu")
> review missed for e8dd7a6b54a8 ("mm/damon: fix typos in comments")
> review missed for 999d5100ccf7 ("memcg: rename mem_cgroup_ino() to mem_cgroup_id()")
> '''
>
> The first two patches are false positives of the script, but the last two
> patches were somewhat I actually needed to take more care.  Thanks to Andrew

I mean thanks for putting something forward :) but we'd really need to avoid
false positives and you're going to need all sorts of parameters for this to be
any way useful.

I mean we have people sending series in all kinds of ways, and if somebody sends
a v3 for a v2 that had tonnes of review we don't want to hear about that.

And for instance a huge series like Nico's I _am well aware of_ and don't need
nagging about.

In my opinion this is something for each individual sub-maintainer to keep track
of, and really submitters need to get used to resending if necessary.

I think the point Andrew was making here was to track _hotfixes_ especially, and
so you'd need to narrow down to those and really only those from at least 1 or 2
weeks ago that were not yet merged.

But we also can't do any of this without clarity on how the trees work.

Right now it's totally unclear how and when and why patches go to different
trees.

So any kind of effort like this is predacated on a bunch of other change
happening first, and I'm really losing any hope that any of that will happen at
this stage.

> adding Link: tag to each patch on mm tree, taking the followup action was also
> super easy and smooth for me.  I like the results more than I expected, and
> decided to keep using the script.
>
> And I now realize this approach would also work for people who didn't list
> their name on MAINTAINERS but still looking for patches to review.
>
> Even though the idea and the script may not work for others, I just wanted to
> share this, only hoping it helps finding another idea, whatever other than the
> Patchwork [1].
>
> [1] No offence but a joke, Pedro ;)  Sorry if it was not funny.
>
>
> Thanks,
> SJ
>
> [...]
>

Thanks for the input overall, but unless we change the default-merge policy all
of this is completely moot.

I imagine this will have the same impact as my saying I am no longer going to be
using/checking mm-new, but I'm pulling back from review quite a bit while things
remain as they are (you may have noticed I have already significantly reduced
it).

The current approach is unworkable and I burned out on review a couple cycles
ago when we had the insane influx (esp to THP).

So while tooling is nice and all, you still need people to do the reviewing.

And while mm is 'jump on it or it gets merged' it's just pushing all the stress
down to the people doing the actual work, no matter what tooling we use.

We need to change that in my opinion, but I'm no longer hopeful that we will any
time soon.

Cheers, Lorenzo