Re: FAILED: patch "[PATCH] mm/damon/core: disallow max < min damos filter range arguments commit" failed to apply to 7.3-stable tree

[SJ Park <sj@kernel.org>]

On Sat,  7 Nov 2026 09:36:36 -0800 SJ Park <sj@kernel.org> wrote:

> On Sat,  7 Nov 2026 05:04:27 -0500 Sasha Levin <sashal@kernel.org> wrote:
> 
> > The patch below does not apply to the 7.3-stable tree.
> > If someone wants it applied there, or to any other stable or longterm
> > tree, then please email the backport, including the original git commit
> > id to <stable@vger.kernel.org>.
> > 
> > To reproduce the conflict and resubmit, you may use the following commands:
> > 
> > git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-7.3.y
> > git checkout FETCH_HEAD
> > git cherry-pick -x 1bfb9384ae0ed52d61eb601b655014b7815ff849
> > # <resolve conflicts, build, test, etc.>
> > git commit -s
> > git send-email --to '<stable@vger.kernel.org>' --in-reply-to '20261107050426-failed-7.3-1bfb9384ae0e@kernel.org' --subject-prefix 'PATCH 7.3.y' 'HEAD^..'
> > 
> > Thanks,
> > Sasha
> > 
> > ------------------ original commit in Linus's tree ------------------
> > 
> > >From 1bfb9384ae0ed52d61eb601b655014b7815ff849 Mon Sep 17 00:00:00 2001
> > From: SJ Park <sj@kernel.org>
> > Date: Mon, 14 Sep 2026 07:23:21 -0700
> > Subject: [PATCH] mm/damon/core: disallow max < min damos filter range
> >  arguments commit
> > 
> > damos_commit_filter_arg() receives range arguments for a few types of
> > DAMOS filters.  It allows any range including max < min range.  It is fine
> > for the logic, but makes no sense to support it.  Actually DAMON sysfs
> > interface is doing the validation on its own.  To avoid duplicated
> > validations in multiple DAMON API callers, it would be better to do the
> > validation in the core layer.  Add a validation of the given range.
> > 
> > Link: https://lore.kernel.org/20260914142327.92510-5-sj@kernel.org
> > Signed-off-by: SJ Park <sj@kernel.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Brendan Higgins <brendan.higgins@linux.dev>
> > Cc: David Gow <davidgow@davidgow.net>
> > Cc: Usama Arif <usamaarif642@gmail.com>
> > Cc: <stable@vger.kernel.org>
> 
> Including this, five DAMON patch cherry-pick failures [1,2,3,4] for 7.3.y are
> reported last night
> 
> The patchex except the last one [4] don't Cc: stable@ and look like not
> essential hotfixes.
> 
> Those are refactoring [1,2] or a very minor fix [3] that doesn't really impact
> users.  Those are not built in porting-friendly way because those were not
> meant to be hotfixes.  To port those, no small amount of refactoring or porting
> of more dependencies are expected.
> 
> I don't mind porting non-Cc: stable@ DAMON patches to stable kernels.  And I'm
> happy to help doing that.  But I'm not quite sure if this is indeed what you
> want, or picked by a mistake.  Could you please confirm?

TL;DR: The four patches wrongly have Cc: stable@ tags.  Let's ignore these.

I just found mainline commits for those patches do have Cc: stable@.

The patches I posted [1] don't have Cc: stable@.  But Cc: stable@ tags are
added to the patches inside mm.git.  Apparently because I posted those as a
part of a series that have both Cc:stable@ and non-Cc:stable@ patches.  I
shouldn't mixed those.  Refer to other thread [2] of the same finding for more
details.

And because they don't have Fixes:, seems it was tried to be applied to entire
stable kernels.  I show similar cherry-pick failure results from these patches.
Sorry again for this complicated situation.

So, I'd suggest to not add this and three more cherry-pick failed patches
[1,2,3] to stable series.  There are two more non-Cc:stable patches in the
series.  Apparently those might also merged into the mainline with the wrong
Cc:stable@ tags.  Hence those may also be tried to be applied to stable
kernels.

In lucky cases, those may failed like this.  We can simply ignore those.  If
some of those are unluckily successfully cherry-picked, and if those don't make
some test failures, maybe we could simply keep those.

Let me know if you'd prefer just adding those, or finding and dropping those
wrongly applied ones from series before released.  I could also help in any
case.

[1] https://lore.kernel.org/20260914142327.92510-1-sj@kernel.org
[2] https://lore.kernel.org/20261107183202.177477-1-sj@kernel.org

> 
> [1] https://lore.kernel.org/20261107050429-failed-7.3-1d2397b2c414@kernel.org
> [2] https://lore.kernel.org/20261107050431-failed-7.3-cec08aad3def@kernel.org
> [3] https://lore.kernel.org/20261107050434-failed-7.3-af19aff38d6f@kernel.org
> [4] https://lore.kernel.org/20261107050537-failed-7.3-5695abc4e742@kernel.org
> 
> 
> Thanks,
> SJ
> 
> [...]
> 


Thanks,
SJ