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

So sure, include this with the patch, whatever.

Just don't break my test...

>
> --
> Cheers
>
> David
>