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. So sure, include this with the patch, whatever. Just don't break my test... > > -- > Cheers > > David >
