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 <[email protected]> > > > > > Cc: [email protected] > > > > > > > > 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
