From: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
To: sj@kernel.org, akpm@linux-foundation.org
Cc: damon@lists.linux.dev, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, donggeunyoo.kernel@gmail.com,
stable@vger.kernel.org
Subject: [PATCH v3 1/2] mm/damon/core: prevent size quota overflow in the temporal goal tuner
Date: Sun, 20 Sep 2026 21:24:10 +0900 [thread overview]
Message-ID: <20260920122411.610213-2-donggeunyoo.kernel@gmail.com> (raw)
In-Reply-To: <20260920122411.610213-1-donggeunyoo.kernel@gmail.com>
damos_goal_tune_esz_bp_temporal() converts the scheme's size quota
into basis points with "quota->esz_bp = quota->sz * 10000", both
unsigned long, and damos_set_effective_quota() divides the result
back by 10000. quotas/bytes is unbounded; bytes_store() hands it to
kstrtoul() as is.
On 32-bit the product wraps for any size quota above ULONG_MAX /
10000, that is 429496 bytes. It lands on exactly zero when the quota
is a multiple of 256 MiB, which includes the 1 GiB that
Documentation/admin-guide/mm/damon/usage.rst uses in its example, and
a zero effective quota makes damos_quota_is_full() true on the first
test of every charge window. The scheme then applies nothing while
the goal is unachieved. Other wrapped values are simply wrong, and
any product below 10000 divides to a zero effective quota too: 429497
gives 0, 500000 gives 70503.
Triggering this needs a scheme with a quota goal, the temporal goal
tuner, and a size quota above ULONG_MAX / 10000 -- 429496 bytes on
32-bit, 1844674407370955 on 64-bit -- so it is unlikely to be hit on
a tested setup. Nothing is corrupted and nothing leaks. The scheme
makes no progress for as long as the goal is unachieved, which is
easy to notice, and writing a smaller size quota restores it.
addr_unit does not cover this. It only scales the numbers a paddr
context writes to quotas/bytes, so a large enough scaled value wraps
just the same, and vaddr and fvaddr contexts take raw byte values.
Bound the multiply. A size quota too large to convert now takes the
same ULONG_MAX branch as a scheme with no size quota, so the
effective quota becomes ULONG_MAX / 10000 instead of a wrapped value.
Fixes: af738a6a00c1 ("mm/damon/core: introduce DAMOS_QUOTA_GOAL_TUNER_TEMPORAL")
Cc: <stable@vger.kernel.org> # 7.1.x
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
---
Measured on i386 under QEMU: one paddr context with a stat scheme, the
temporal goal tuner, and one unachieved user_input goal. Each size is
written to quotas/bytes and quotas/effective_bytes is read back after
update_schemes_effective_quotas.
quotas/bytes effective_bytes effective_bytes
before after
4096 4096 4096
429496 429496 429496
429497 0 429496
268435456 0 429496
1073741824 0 429496
500000 70503 429496
4294967295 429495 429496
0 429496 429496
Everything the conversion can hold is unchanged, and 429496 is what the
no-size-quota row already produced before the patch.
mm/damon/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 2258b72da7a78..16d4145379a2b 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -3274,7 +3274,7 @@ static void damos_goal_tune_esz_bp_temporal(struct damon_ctx *c,
if (score >= 10000)
quota->esz_bp = 0;
- else if (quota->sz)
+ else if (quota->sz && quota->sz <= ULONG_MAX / 10000)
quota->esz_bp = quota->sz * 10000;
else
quota->esz_bp = ULONG_MAX;
--
2.53.0
next prev parent reply other threads:[~2026-09-20 12:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 12:24 [PATCH v3 0/2] mm/damon: fix the temporal goal tuner's size quota conversion Donggeun Yoo
2026-09-20 12:24 ` Donggeun Yoo [this message]
2026-09-20 12:24 ` [PATCH v3 2/2] mm/damon/tests/core-kunit: test the temporal " Donggeun Yoo
2026-09-20 12:41 ` [PATCH v3 0/2] mm/damon: fix the temporal goal " SJ Park
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=20260920122411.610213-2-donggeunyoo.kernel@gmail.com \
--to=donggeunyoo.kernel@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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
all inboxes | Powered by JetHome®