Re: [PATCH 6.18.y] mm/damon/core: avoid infinite kdamond_merge_regions() internal loop

[SJ Park <sj@kernel.org>]

On Wed, 9 Sep 2026 15:03:16 +0200 Greg KH <greg@kroah.com> wrote:

> On Tue, Sep 08, 2026 at 09:15:02PM -0700, SJ Park wrote:
> > Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and
> > races", v1.1.
> > 
> > Sashiko found a few issues in DAMON that could cause infinite loop, NULL
> > dereference and monitoring results degradation.  The first two sounds
> > scary but the infinite loop happens only under unreasonable user setup.
> > The NULL dereference is only in a unit test.  Monitoring results
> > degradation is trivial since it is only best-effort, and those happens
> > from only unlikely races.  Still those are bugs that better to fix if
> > possible.  Fix those.
> > 
> > This patch (of 6):
> > 
> > Due to online parameter update like events, the number of DAMON regions
> > could be higher than the user-set upper limit.  kdamond_merge_regions()
> > repeats merge regions until the number meets the limit, while doubling the
> > merge threshold up to the theoretical maximum threshold.  It is tried only
> > up to the theoretical maximum threshold because even the aggressive
> > merging can fail from reducing the number of regions under the
> > user-defined upper limit.  For example, there could be many user-defined
> > non-contiguous regions that cannot be merged.
> > 
> > The threshold based loop break condition is evaluated by comparing the
> > threshold for the next merging try against the theoretical maximum
> > threshold.  If max_thres is larger than UINT_MAX / 2, doubling the
> > threshold could make it overflow, and bypass the loop break condition.  In
> > the case, if the number of regions cannot be reduced under the upper limit
> > like explained above, the loop will run infinitely.
> > 
> > Prevent the case by doing the break condition check before doubling the
> > threshold.  Also, prevent the threshold exceeding the maximum threshold,
> > as it could overflow and apply the wrong merge threshold.
> > 
> > This issue is unlikely to occur in real world, since having the max_thres
> > higher than UINT_MAX / 2 require unrealistically large aggregation
> > intervals compared to the sampling interval.  Also, it requires an
> > unrealistically large number of uncontiguous regions setup.  Nonetheless,
> > the consequence is bad and the fix is simple.
> > 
> > The issue was discovered [1] by Sashiko.
> > 
> > Link: https://lore.kernel.org/20260715031002.108504-1-sj@kernel.org
> > Link: https://lore.kernel.org/20260715031002.108504-2-sj@kernel.org
> > Link: https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org [1]
> > Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr_regions is unmet")
> > Signed-off-by: SJ Park <sj@kernel.org>
> > Cc: <stable@vger.kernel.org> # 6.10.x
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > (cherry picked from commit 123e4619ab6c8ab1c4cb1d7a58311a2af13929cd)
> > Signed-off-by: SJ Park <sj@kernel.org>
> > ---
> >  mm/damon/core.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 70ac1f08753d1..08e527efd6883 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -2411,15 +2411,20 @@ static void kdamond_merge_regions(struct damon_ctx *c, unsigned int threshold,
> >  
> >  	max_thres = c->attrs.aggr_interval /
> >  		(c->attrs.sample_interval ?  c->attrs.sample_interval : 1);
> > -	do {
> > +	while (true) {
> >  		nr_regions = 0;
> >  		damon_for_each_target(t, c) {
> >  			damon_merge_regions_of(t, threshold, sz_limit);
> >  			nr_regions += damon_nr_regions(t);
> >  		}
> > -		threshold = max(1, threshold * 2);
> > -	} while (nr_regions > c->attrs.max_nr_regions &&
> > -			threshold / 2 < max_thres);
> > +		if (nr_regions <= c->attrs.max_nr_regions ||
> > +				max_thres <= threshold)
> > +			break;
> > +		if (threshold < max_thres / 2)
> > +			threshold = max(1, threshold * 2);
> > +		else
> > +			threshold = max_thres;
> > +	}
> >  }
> >  
> >  /*
> > -- 
> > 2.47.3
> > 
> > 
> 
> Does not apply :(

Seems another patch in 6.18.51..6.18.51-rc1 is causing the conflict.  I just
confirmed the original commit can clealy cherry-picked on 6.18.51-rc1.  Could
you please add that?  Let me know if there is something that I can help :)


Thanks,
SJ

[...]