Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: SJ Park <sj@kernel.org>
Cc: stable@vger.kernel.org, damon@lists.linux.dev,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 6.18.y] mm/damon/core: avoid infinite kdamond_merge_regions() internal loop
Date: Wed, 9 Sep 2026 15:03:16 +0200	[thread overview]
Message-ID: <2026090910-flypaper-elixir-5106@gregkh> (raw)
In-Reply-To: <20260909041502.181947-1-sj@kernel.org>

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 :(

  reply	other threads:[~2026-09-09 13:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08 12:52 FAILED: patch "[PATCH] mm/damon/core: avoid infinite kdamond_merge_regions()" failed to apply to 6.18-stable tree gregkh
2026-09-09  4:15 ` [PATCH 6.18.y] mm/damon/core: avoid infinite kdamond_merge_regions() internal loop SJ Park
2026-09-09 13:03   ` Greg KH [this message]
2026-09-10  0:37     ` SJ Park
2026-09-11 11:20   ` Sasha Levin
2026-09-11 13:50     ` SJ Park
2026-09-15  2:03       ` Sasha Levin
2026-09-11 13:49 ` [PATCH 6.18.y v2] " SJ Park
2026-09-12 15:26   ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2026090910-flypaper-elixir-5106@gregkh \
    --to=greg@kroah.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=sj@kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox