From: sashiko-bot@kernel.org
To: "Jason Angelov" <jasonangelov@ucla.edu>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 1/2] mm/damon/core-kunit: test probe_hits handling at region split and merge
Date: Tue, 18 Aug 2026 03:57:42 +0000 [thread overview]
Message-ID: <20260818035742.F0E5A1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260818034552.11975-2-jasonangelov@ucla.edu>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but there is an integer overflow in damon_merge_two_regions() when calculating size-weighted averages on 32-bit architectures.
--
--- Patch [1]: [PATCH 1/2] mm/damon/core-kunit: test probe_hits handling at region split and merge ---
commit f275f8ec2d833d0e2eacc7a18ba7c56b04b7e599
Author: Jason Angelov <jasonangelov@ucla.edu>
mm/damon/core-kunit: test probe_hits handling at region split and merge
Extend damon_test_split_at() and damon_test_merge_two() tests to cover
handling of probe_hits and last_probe_hits arrays.
> diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h
> index 4a536d41cdb2d..2db94d49c9bae 100644
> --- a/mm/damon/tests/core-kunit.h
> +++ b/mm/damon/tests/core-kunit.h
[ ... ]
> @@ -204,6 +210,7 @@ static void damon_test_merge_two(struct kunit *test)
> KUNIT_EXPECT_EQ(test, r->ar.start, 0ul);
> KUNIT_EXPECT_EQ(test, r->ar.end, 300ul);
> KUNIT_EXPECT_EQ(test, r->nr_accesses, 16u);
> + KUNIT_EXPECT_EQ(test, r->probe_hits[0], 11);
[Severity: High]
This is a pre-existing issue, but does the size-weighted average logic
tested here overflow on 32-bit architectures?
Looking at mm/damon/core.c:damon_merge_two_regions(), the calculations
multiply values like nr_accesses and probe_hits by the region size in bytes:
mm/damon/core.c:damon_merge_two_regions() {
...
l->nr_accesses = (l->nr_accesses * sz_l + r->nr_accesses * sz_r) /
(sz_l + sz_r);
...
for (i = 0; i < DAMON_MAX_PROBES; i++)
l->probe_hits[i] = (l->probe_hits[i] * sz_l + r->probe_hits[i]
* sz_r) / (sz_l + sz_r);
...
}
On a 32-bit architecture, unsigned long is 32 bits (max ~4.29GB). If a
region is just 17MB and probe_hits is 255, the multiplication
255 * 17,000,000 evaluates to ~4.33GB, which would silently truncate.
Could this wrap-around cause merged regions to inherit drastically incorrect
statistics, potentially misidentifying hot memory as cold and triggering
aggressive paging out of actively used pages?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260818034552.11975-1-jasonangelov@ucla.edu?part=1
next prev parent reply other threads:[~2026-08-18 3:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 3:45 [PATCH 0/2] mm/damon: add kunit tests for probe_hits handling and probe params validation Jason Angelov
2026-08-18 3:45 ` [PATCH 1/2] mm/damon/core-kunit: test probe_hits handling at region split and merge Jason Angelov
2026-08-18 3:57 ` sashiko-bot [this message]
2026-08-18 4:46 ` SJ Park
2026-08-18 4:50 ` SJ Park
2026-08-18 3:45 ` [PATCH 2/2] mm/damon/core-kunit: test damon_valid_probe_params() Jason Angelov
2026-08-18 3:50 ` sashiko-bot
2026-08-18 4:55 ` SJ Park
2026-08-18 4:58 ` [PATCH 0/2] mm/damon: add kunit tests for probe_hits handling and probe params validation 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=20260818035742.F0E5A1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=jasonangelov@ucla.edu \
--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.