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 Fri, Jan 09, 2026 at 03:16:57PM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/8/26 07:26, 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.
> >
> > >
> > > Perhaps it's time to deploy something like Patchwork to help track
> > > outstanding patches?
> >
> > 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.
> >
> > 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.
>
> I have my inbox full with stuff that needs review. As long as I am properly
> getting CCed, I am well aware.
>
> What needs review is at least not my problem. And people can feel free to be
> listed as Reviewer to get CCed :)
>
> The problem I have is that if I am not fast enough to review/ack, things
> might go upstream.
>
> It sucks. Hard.

Yup :)

I'm opting out of this game. I think the more untenable this becomes the more
sub-maintainers will do the same, which is not good for anybody.

If we are unable to even determine whether patches land upstream, what does it
actually mean? We do all the work, then still - unless we burn ourselves out
jumping on everything - we cannot prevent broken changes going upstream.

It was an irritation in the past, with the current rate of submissions it's
become completely unsustainable.

mm needs to change or it's going to simply fall apart as a subsystem.

>
> --
> Cheers
>
> David

Cheers, Lorenzo