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 :(
next prev parent 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