From: SeongJae Park <sj@kernel.org>
Cc: SeongJae Park <sj@kernel.org>,
"# 6 . 3 . x" <stable@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
damon@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: [RFC PATCH v1.2 2/2] mm/damon/ops-common: prevent >DAMON_MAX_SUBSCORE freq_subscore
Date: Mon, 22 Jun 2026 07:10:25 -0700 [thread overview]
Message-ID: <20260622141027.29145-3-sj@kernel.org> (raw)
In-Reply-To: <20260622141027.29145-1-sj@kernel.org>
When a zero sampling interval and a zero aggregation interval are
online-committed, damon_max_nr_accesses() will return 1 right after the
update. damon_update_monitoring_results() skips updating nr_accesses of
regions for zero intervals, though. As a result, some regions could
have nr_acceses values that are larger than damon_max_nr_accesses() for
the remaining aggregation window. Note that the remaining aggregation
window will be quite short. It is just the remaining execution of the
kdamond_fn() main loop body, since the aggregation interval is zero.
If damon_hot_score() is called during the remaining aggregation window,
the function can calculate freq_subscore that is larger than
DAMON_MAX_SUBSCORE. Depending on the score weights and age/size scores,
damon_hot_score() can now return a score that is higher than
DAMOS_MAX_SCORE.
damos_adjust_quota(), which is an indirect caller of damon_hot_score()
uses the score as an index to regions_score_histogram array. The
array's size is set to only DAMOS_MAX_SCORE + 1. As a result, an
out-of-bound array access can happen.
The issue is expected to happen only rarely in the real world. After
all, zero aggregation interval is not supposed to be common. Also, the
online commit of zero intervals should be made on exactly when the DAMOS
scheme will be triggered. I was unable to trigger this on my own.
Nonetheless, it is possible in theory and the consequence is bad.
Fix the problem by applying an upper bound of the freq_subscore. This
is a short term fix. In the long term,
damon_update_monitoring_results() should be modified to update all
monitoring results even in case of zero aggregation interval. Add that
as a TODO.
The issue was discovered [1] by Sashiko.
[1] https://lore.kernel.org/20260621175849.91990-1-sj@kernel.org
Fixes: 2f5bef5a590b ("mm/damon/core: update monitoring results for new monitoring attributes")
Cc: <stable@vger.kernel.org> # 6.3.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/ops-common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
index 5c93ef2bb8a97..8d516851a69e4 100644
--- a/mm/damon/ops-common.c
+++ b/mm/damon/ops-common.c
@@ -115,6 +115,9 @@ int damon_hot_score(struct damon_ctx *c, struct damon_region *r,
freq_subscore = r->nr_accesses * DAMON_MAX_SUBSCORE /
damon_max_nr_accesses(&c->attrs);
+ /* TODO: update monitoring results always to avoid this. */
+ if (freq_subscore > DAMON_MAX_SUBSCORE)
+ freq_subscore = DAMON_MAX_SUBSCORE;
age_in_sec = (unsigned long)r->age * c->attrs.aggr_interval / 1000000;
if (age_in_sec)
--
2.47.3
prev parent reply other threads:[~2026-06-22 14:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 14:10 [RFC PATCH v1.2 0/2] mm/damon: handle zero {sample,aggr} intervals for DAMOS quota score SeongJae Park
2026-06-22 14:10 ` [RFC PATCH v1.2 1/2] mm/damon/core: handle zero intervals in damon_max_nr_accesses() SeongJae Park
2026-06-22 14:10 ` SeongJae Park [this message]
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=20260622141027.29145-3-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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