Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,stable@vger.kernel.org,sj@kernel.org,donggeunyoo.kernel@gmail.com,akpm@linux-foundation.org
Subject: [merged mm-stable] mm-damon-core-prevent-size-quota-overflow-in-the-temporal-goal-tuner.patch removed from -mm tree
Date: Sat, 24 Oct 2026 01:58:12 -0700	[thread overview]
Message-ID: <20261024085812.D6B521F01825@smtp.kernel.org> (raw)


The quilt patch titled
     Subject: mm/damon/core: prevent size quota overflow in the temporal goal tuner
has been removed from the -mm tree.  Its filename was
     mm-damon-core-prevent-size-quota-overflow-in-the-temporal-goal-tuner.patch

This patch was dropped because it was merged into the mm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

------------------------------------------------------
From: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Subject: mm/damon/core: prevent size quota overflow in the temporal goal tuner
Date: Mon, 28 Sep 2026 01:48:14 -0700

Patch series "mm/damon: fix the temporal goal tuner's size quota
conversion", v5.

damos_goal_tune_esz_bp_temporal() hands the size quota to
damos_set_effective_quota() through quota->esz_bp in basis points, and the
multiply that gets it there is unchecked.  On 32-bit it wraps above 429496
bytes, and a wrapped product below 10000 divides to a zero effective
quota.  damos_quota_is_full() is then true on the first test of every
charge window, so the scheme makes no progress for as long as the goal is
unachieved.

Patch 1 bounds the conversion.  Patch 2 pins the boundary in the core
kunit suite, where the new test would fail without patch 1 on any word
size.


This patch (of 2):

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.  A wrapped product below 10000 divides to a zero
effective quota: 429497 gives 0.  damos_quota_is_full() is then true on
the first test of every charge window.  Other wrapped values are wrong
without being zero: 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.  The scheme then makes no progress for as long
as the goal is unachieved, which is easy to notice, and writing a smaller
size quota restores it.  Nothing is corrupted and nothing leaks.  This is
unlikely to be hit on a tested setup.

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.

Link: https://lore.kernel.org/20260928084816.5575-1-sj@kernel.org
Link: https://lore.kernel.org/20260928084816.5575-2-sj@kernel.org
Fixes: af738a6a00c1 ("mm/damon/core: introduce DAMOS_QUOTA_GOAL_TUNER_TEMPORAL")
Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com>
Signed-off-by: SJ Park <sj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: SJ Park <sj@kernel.org>
Cc: <stable@vger.kernel.org> # 7.1.x
---

 mm/damon/core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/damon/core.c~mm-damon-core-prevent-size-quota-overflow-in-the-temporal-goal-tuner
+++ a/mm/damon/core.c
@@ -3291,7 +3291,7 @@ static void damos_goal_tune_esz_bp_tempo
 
 	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;
_

Patches currently in -mm which might be from donggeunyoo.kernel@gmail.com are

userfaultfd-clear-the-inherited-uffd-bit-in-move_swap_pte.patch


                 reply	other threads:[~2026-10-24  8:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20261024085812.D6B521F01825@smtp.kernel.org \
    --to=akpm@linux-foundation.org \
    --cc=donggeunyoo.kernel@gmail.com \
    --cc=mm-commits@vger.kernel.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