linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
	"Mikulas Patocka" <mpatocka@redhat.com>,
	"Christian König" <christian.koenig@amd.com>,
	"David Hildenbrand" <david@redhat.com>,
	amd-gfx@lists.freedesktop.org, linux-mm@kvack.org
Subject: Re: [PATCH v2] fix AMDGPU failure with periodic signal
Date: Tue, 6 Jan 2026 18:24:10 +0000	[thread overview]
Message-ID: <52bffed4-d9b0-4ec9-85a6-ba70e22106f3@lucifer.local> (raw)
In-Reply-To: <20260106101249.be7514e75c09a928c6fa71ef@linux-foundation.org>

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

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.

Again, requiring an M signoff fixes this completely.

No patch should be merged without review, most certainly not one expedited
to an -rc.

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

Cheers, Lorenzo


  reply	other threads:[~2026-01-06 18:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-07 17:48 Mikulas Patocka
2026-01-02 19:02 ` Lorenzo Stoakes
2026-01-02 19:08   ` Lorenzo Stoakes
2026-01-03 17:58     ` Andrew Morton
2026-01-05 10:43       ` Lorenzo Stoakes
2026-01-04 21:12   ` Mikulas Patocka
2026-01-05 10:45     ` Lorenzo Stoakes
2026-01-05 10:59       ` Lorenzo Stoakes
2026-01-02 19:15 ` Lorenzo Stoakes
2026-01-06 11:51 ` Lorenzo Stoakes
2026-01-06 18:12   ` Andrew Morton
2026-01-06 18:24     ` Lorenzo Stoakes [this message]
2026-01-06 20:59       ` Andrew Morton
2026-01-06 21:52         ` Pedro Falcato
2026-01-08  6:26           ` Finding mm patches to review before those are pulled into the mainline (was "Re: [PATCH v2] fix AMDGPU failure with periodic signal") SeongJae Park
2026-01-08  9:05             ` Lorenzo Stoakes
2026-01-07 12:33         ` [PATCH v2] fix AMDGPU failure with periodic signal Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52bffed4-d9b0-4ec9-85a6-ba70e22106f3@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mpatocka@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox