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

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

[Mikulas Patocka]

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

---
 tools/testing/vma/vma_internal.h |    5 +++++
 1 file changed, 5 insertions(+)

Index: mm/tools/testing/vma/vma_internal.h
===================================================================
--- mm.orig/tools/testing/vma/vma_internal.h	2026-01-04 21:19:10.000000000 +0100
+++ mm/tools/testing/vma/vma_internal.h	2026-01-04 21:19:10.000000000 +0100
@@ -1364,6 +1364,11 @@ static inline bool signal_pending(void *
 	return false;
 }
 
+static inline bool fatal_signal_pending(void *p)
+{
+	return false;
+}
+
 static inline bool is_file_hugepages(struct file *file)
 {
 	return false;

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

[Lorenzo Stoakes]

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?

>
> ---
>  tools/testing/vma/vma_internal.h |    5 +++++
>  1 file changed, 5 insertions(+)
>
> Index: mm/tools/testing/vma/vma_internal.h
> ===================================================================
> --- mm.orig/tools/testing/vma/vma_internal.h	2026-01-04 21:19:10.000000000 +0100
> +++ mm/tools/testing/vma/vma_internal.h	2026-01-04 21:19:10.000000000 +0100
> @@ -1364,6 +1364,11 @@ static inline bool signal_pending(void *
>  	return false;
>  }
>
> +static inline bool fatal_signal_pending(void *p)
> +{
> +	return false;
> +}
> +
>  static inline bool is_file_hugepages(struct file *file)
>  {
>  	return false;
>
>

Thanks, Lorenzo

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

[David Hildenbrand (Red Hat)]

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.

-- 
Cheers

David

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

[Lorenzo Stoakes]

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
>

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

[David Hildenbrand (Red Hat)]

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.

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.

-- 
Cheers

David

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

[Lorenzo Stoakes]

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

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

[Andrew Morton]

On Mon, 5 Jan 2026 12:18:59 +0000 Lorenzo Stoakes <lorenzo.stoakes@oracle.com> 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,

Well they have different routes into mainline.  cc:stable stuff goes
into current -rc and non-cc:stable material goes into next -rc1.  They
land in different branches of mm.git.  So it's best to separate these
things.

otoh, if the fix isn't urgent (like this one) then it's OK to add
cc:stable material into next -rc1 - it'll get there eventually.

> but I'm not sure how exactly we
> are supposed to express order here otherwise. Andrew?

hm.  We could just fix the bug, then when that fix lands in mainline
and has a stable hash we could prepare selftests fixups with
Fixes:that.

I do feel that Fixes: is a bit of a misnomer.  I treat it as a message
from us to -stable maintainers:
Please-add-this-to-any-kernel-which-contains: