Re: [PATCH v3 1/3] tools/testing/vma/vma_internal.h: provide fatal_signal_pending

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

On Mon, Jan 05, 2026 at 04:47:30PM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/5/26 16:36, Lorenzo Stoakes wrote:
> > On Mon, Jan 05, 2026 at 04:06:38PM +0100, David Hildenbrand (Red Hat) wrote:
> > > On 1/5/26 13:18, Lorenzo Stoakes wrote:
> > > > On Sun, Jan 04, 2026 at 10:15:36PM +0100, Mikulas Patocka wrote:
> > > > > Provide a dummy function fatal_signal_pending, because it will be used in
> > > > > the following patch in the function mm_take_all_locks.
> > > > >
> > > > > This commit avoids a test failure when the following patch will be apllied.
> > > > >
> > > > > Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> > > > > Cc: stable@vger.kernel.org
> > > >
> > > > No, please don't cc stable. Also don't cc stable without a Fixes tag.
> > > >
> > > > This isn't backportable given you now need to backport to 5.10, 5.15, 6.1, 6.6,
> > > > 6.12, 6.17.
> > > >
> > > > I'm not sure how Andrew deals with a mix of Cc: stable and not-cc-stable patches
> > > > in a series, think he generally doesn't like, but I'm not sure how exactly we
> > > > are supposed to express order here otherwise. Andrew?
> > >
> > > Can't we just have this hunk here as part of patch #2?
> > >
> > > Backporting should be rather simple, just drop the hunk on kernels where it
> > > doesn't apply. Sure, a bit of manual work, but better than making our life
> > > more complicated here.
> > >
> > > But maybe I am missing something.
> >
> > Because the patch was sent with patch sending-101 issues (yet still merged to
> > hotfix queue inexplicably) so I assumed manual fixups might be problematic.
> >
> > But actually because we moved mm_take_all_locks() between files it'll need
> > manual fixups anyway.
>
> Yeah, that's what I thought. Backports might not be that easy either way.

The point was to assert an ordering so in tip this fix is done ahead of the
change to prevent bad bisects etc., then to leave the backported bit as simple
as possible, since it's a total pain.

>
> Sending+testing stable backports is not particularly fun (I have some in my
> inbox ...), but sometimes it only requires one backported version that can
> just be used for all older kernels.

Yup it's ideal if it can be automatic but in this case it just won't be.

This is also why I suggested separating out the driver fix, though I think that
patch is probably not even necessary as I reviewed.

>
> --
> Cheers
>
> David
>

Thanks, Lorenzo