Re: [PATCH v2] fix AMDGPU failure with periodic signal

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

On Tue, Jan 06, 2026 at 12:59:12PM -0800, Andrew Morton wrote:
> On Tue, 6 Jan 2026 18:24:10 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > On Tue, Jan 06, 2026 at 10:12:49AM -0800, Andrew Morton wrote:
> > > On Tue, 6 Jan 2026 11:51:49 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > >
> > > > I'm not sure if the git repos are lagging vs. quilt, but as reported this
> > > > patch breaks the VMA tests, and the tests are _still_ broken.
> > > >
> > > > Yet it's still in mm-new, mm-unstable, and even mm-hotfixes-unstable.
> > > >
> > > > This is interfering with my work, can we please drop this.
> > > >
> > > > Also the v3 is currently being debated, so surely should have been dropped
> > > > until we have this resolved?
> > >
> > > Well.  I don't drop fixes unless it's decided to be a non-issue or
> > > unless a better fix is available.
> >
> > Even if it breaks the build and that's been reported on-list?
>
> I addressed that.

I don't recall? If it's just git tree lag fine.

>
> > >
> > > I've done this for ever - I've held onto "wrong" fixes for *years*.
> > > View this as a weird issue-tracking system for a project which has no
> > > issue-tracking system.  It's to prevent issues from falling through
> > > cracks and getting lost.
> >
> > I think a lot of the issue is these processes seem to work to you but those
> > on the ground are finding them not to work.
> >
> > The kernel today is not the same as the kernel X years ago, esp. in terms
> > of sheer volume.
> >
> > Having a patch that none of the relevant maintainers/reviewers have seen
> > land in an -rc out of the blue is a really serious problem.
>
> It isn't in -rc.  It's in mm-hotfixes-unstable and it's marked "acks?",
> which means not to go upstream without further consideration.

OK this is another inscrutible part of the process, my understanding of
mm-hotfixes-unstable was 'will go to -rc unless otherwise noted', now it seems
to be 'maybe rc maybe not, but unlike other series, negative review will not
drop this from the tree, even if it causes compile issues'.




>
> > Also it was taken 2 months after it was submitted, so nobody could have
> > _possibly_ picked this up by reading the list. This is why I am really
> > underlining this case.
>
> That's why I grabbed it.  Had I not done so, this issue would have been
> lost.  What I do *worked*.

Um what worked? You didn't ping any reviewers/maintainers, there was no
recent mail on the mailing list for anybody to notice, your process would
have resulted in this patch going into an -rc without review right?

Was the hope that somebody would notice in a release kernel that something
was broken at some stage? I really do hope the process isn't to rely on
that?

It's only because I happened to notice this (it broke my tests) that
there's even been any review, and note that the patch itself was broken (no
fixes tag, numerous issues) + has caused much debate - that was because of
_my_ efforts.

I think the problem here is your processes are pushing down work onto other
people. Merging patches without maintainer signoff forces reviewers to jump
on things out of fear broken things will be merged (as they have been MANY
times).

I would humbly suggest you listen to the people doing the actual work
here. It may to you seem that your approach works, but if the people who
are doing the work required are telling you it's not, then surely it serves
the community better to listen to them?

I am for instance no longer going to be checking mm-new, and I feel that I
was one of the only people to actually try to report build/test issues
there.

>
> > >
> > > It's unfortunate that this one causes disruption so I guess I'll loudly
> > > comment it out and track the issue that way.
> > >
> >
> > I think we need a better approach, yes.
> >
> > We in mm are really very responsive compared to most, I think asking people
> > to wait and resend if somehow it got missed is considerably saner than
> > 'well I'll take any patch purporting to be a fix from anyone so we keep
> > track of stuff'.
>
> If someone wants to step up and be MM issue tracking person then great.
> I don't want to be that person.

You're not tracking issues, you're tracking submitted bug fixes that may or
may not be valid, and deferring the actual work of checking that to others.

I don't think arbitrarily accepting fix patches is helpful here at all.

And surely keeping a list of submitted patches and a reminder to ping
people (if they were cc'd...!) to look at them is not too egregious?

I could take a look at doing that if you're not happy to do that, though
I'd really want to feel my work would be appreciated, and that's not really
the impression I'm getting lately.

>
> And let me reiterate: had I not done this, the issue Mikulas identified
> would have remained unaddressed.
>

Firstly it's highly dubious there is any issue here (see review).

But more importantly - this is simply not true, you queueing this to be
merged without notifying anybody, and the email being 2 months old, meant
nobody could possibly have predicted it landing (you'd have to be reading
every mail in mm-commits too...)

So the most likely outcome here is this would have got merged unreviewed
with nobody realising, including the people who maintain mm/vma.c which it
changes.

Again it took the work of the actual reviewers for this to get
attention. The correct course here would have been to ping the memory
mapping people, tell Mikulas to cc- us in future, then await maintainer
sign-off.

Thanks, Lorenzo