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

["David Hildenbrand (Red Hat)" <david@kernel.org>]

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