All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 7/7] mm/damon/core: handle extreme memory state in get_in_active_mem_bp()
Date: Tue, 01 Sep 2026 13:56:46 +0000	[thread overview]
Message-ID: <20260901135647.3AD7A1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901131326.97615-8-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] 32-bit integer overflow in mult_frac() macro when calculating memory ratio on 32-bit systems, leading to completely incorrect DAMOS quota metrics.
--

commit b2f8512e8018294c2ac5082c2964a0519b9242e8
Author: SJ Park <sj@kernel.org>

mm/damon/core: handle extreme memory state in get_in_active_mem_bp()
    
damos_get_in_active_mem_bp() uses the sum of the active and inactive
memory amount as a denominator.  In an extreme and unlikely environment,
active and inactive memory might be zero.  In this case, hence, it
results in a divide by zero problem.  Avoid it by changing the
denominator to one if it is zero, before it is being used.

[1] https://lore.kernel.org/20260721034756.147011-1-sj@kernel.org

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 6288bb3b09e65..fb96848174dcc 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3005,7 +3005,7 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
>  		global_node_page_state(NR_LRU_BASE + LRU_ACTIVE_FILE);
>  	inactive = global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_ANON) +
>  		global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_FILE);
> -	total = active + inactive;
> +	total = max(active + inactive, 1);
>  	if (active_ratio)
>  		return mult_frac(active, 10000, total);

[Severity: High]
This is a pre-existing issue, but does this calculation overflow on
32-bit systems?

If the active memory size exceeds 429,496 pages (about 1.75 GB), multiplying
the 32-bit unsigned long active variable by 10,000 inside the mult_frac()
macro will overflow ULONG_MAX.

This can result in effectively random DAMON quota metrics on 32-bit systems,
leading DAMON to misinterpret memory states and potentially over-reclaim or
under-reclaim memory.

A similar overflow can also happen in damos_quota_score():

mm/damon/core.c:damos_quota_score() {
    ...
    return mult_frac(goal->current_value, 10000, goal->target_value);
}

Here, goal->current_value multiplied by 10,000 overflows for large values,
such as when microseconds of stall time exceed 430ms.

>  	return mult_frac(inactive, 10000, total);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901131326.97615-1-sj@kernel.org?part=7

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

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 13:13 [PATCH 0/7] damos_apply_scheme() splits a region and apply the action to the SJ Park
2026-09-01 13:13 ` [PATCH 1/7] mm/damon/paddr: respect folio end for DAMOS_STAT SJ Park
2026-09-01 13:23   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 2/7] mm/damon/paddr: respect folio end for DAMOS actions except STAT SJ Park
2026-09-01 13:22   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 3/7] mm/damon/vaddr: respect folio end for DAMOS_STAT SJ Park
2026-09-01 13:33   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 4/7] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} SJ Park
2026-09-01 13:32   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 5/7] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() SJ Park
2026-09-01 13:41   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 6/7] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() SJ Park
2026-09-01 13:46   ` sashiko-bot
2026-09-01 13:13 ` [PATCH 7/7] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() SJ Park
2026-09-01 13:56   ` sashiko-bot [this message]
2026-09-01 13:16 ` [PATCH 0/7] damos_apply_scheme() splits a region and apply the action to the 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=20260901135647.3AD7A1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.