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

[Andrew Morton <akpm@linux-foundation.org>]

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'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.

> 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*.

> >
> > 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.

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