On Mon, 5 Jan 2026 12:18:59 +0000 Lorenzo Stoakes <[email protected]> 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, 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:
