From: sashiko-bot@kernel.org
To: "Liew Rui Yan" <aethernet65535@gmail.com>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric
Date: Fri, 26 Jun 2026 08:24:06 +0000 [thread overview]
Message-ID: <20260626082407.549071F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626081038.46569-1-aethernet65535@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Integer overflow in `DAMOS_WMARK_AVAILABLE_MEM_RATE` metric calculation on 32-bit systems with large RAM.
--
commit 6e3a23f197986b131330f066a94d4821743b7d21
Author: Liew Rui Yan <aethernet65535@gmail.com>
mm/damon/reclaim: add 'available' memory as an optional watermarks metric
This commit introduces a new 'memrate_type' sysfs parameter to DAMON_RECLAIM.
It allows users to switch the watermark metric evaluation from free memory to
available memory, which is particularly useful on devices like Android that
maintain low free memory.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 7e4b9affc5b06..f12d06081d70f 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -3300,11 +3300,17 @@ static bool kdamond_need_stop(struct damon_ctx *ctx)
> static int damos_get_wmark_metric_value(enum damos_wmark_metric metric,
> unsigned long *metric_value)
> {
> + long available_pages;
> +
> switch (metric) {
> case DAMOS_WMARK_FREE_MEM_RATE:
> *metric_value = global_zone_page_state(NR_FREE_PAGES) * 1000 /
> totalram_pages();
> return 0;
> + case DAMOS_WMARK_AVAILABLE_MEM_RATE:
> + available_pages = si_mem_available();
> + *metric_value = available_pages * 1000 / totalram_pages();
[Severity: Low]
Can this calculation overflow on 32-bit systems with a large amount of memory?
Since available_pages is a long type, on 32-bit architectures it is a 32-bit
integer. If the system's available memory exceeds roughly 17.1 GB (about
4,294,967 pages), multiplying available_pages by 1000 before the division would
overflow the maximum 32-bit value.
This truncation could result in an artificially low watermark metric rate.
Would it be safer to cast available_pages to a 64-bit type or use mult_frac()
to prevent the potential overflow, even if such large memory sizes are uncommon
on 32-bit targets?
> + return 0;
> default:
> break;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626081038.46569-1-aethernet65535@gmail.com?part=1
next prev parent reply other threads:[~2026-06-26 8:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 8:10 [RFC PATCH] mm/damon/reclaim: add 'available' memory as an optional watermarks metric Liew Rui Yan
2026-06-26 8:24 ` sashiko-bot [this message]
2026-06-26 14:18 ` SeongJae 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=20260626082407.549071F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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.