From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter
Date: Sun, 13 Sep 2026 17:24:21 +0000 [thread overview]
Message-ID: <20260913172422.3F7811F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260913171133.102366-3-sj@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing initialization and validation of `range_min` and `range_max` for newly appended `hugepage_size` filters leads to uninitialized memory usage.
--
commit 2b0a5f30b2fda9db59b511fc77d64fcbd35378ca
Author: SJ Park <sj@kernel.org>
mm/damon/core: commit hugepage_size type damon filter
Extend data attribute probe filters commit logic for the new
hugepage_size filter type. Since it needs to carry the size range of
the hugepage, update the logic to update the size range fields of the
commit destination filter struct.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 0c98f7e267d07..a3febdc355c1e 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
[ ... ]
> @@ -1807,23 +1807,33 @@ static void damon_commit_filter(struct damon_filter *dst,
> case DAMON_FILTER_TYPE_MEMCG:
> dst->memcg_id = src->memcg_id;
> break;
> + case DAMON_FILTER_TYPE_HUGEPAGE_SIZE:
> + if (src->range_max < src->range_min)
> + return -EINVAL;
> + dst->range_min = src->range_min;
> + dst->range_max = src->range_max;
> + break;
> default:
> break;
> }
> + return 0;
> }
>
> static int damon_commit_filters(struct damon_probe *dst,
> struct damon_probe *src)
> {
[ ... ]
> damon_for_each_filter_safe(src_filter, next, src) {
> if (j++ < i)
> continue;
>
> new_filter = damon_new_filter(src_filter->type,
> src_filter->matching, src_filter->allow);
> if (!new_filter)
> return -ENOMEM;
> switch (src_filter->type) {
> case DAMON_FILTER_TYPE_MEMCG:
> new_filter->memcg_id = src_filter->memcg_id;
> break;
> default:
> break;
> }
> damon_add_filter(dst, new_filter);
[Severity: High]
Does this code leave range_min and range_max uninitialized for newly
appended hugepage_size filters?
If a user writes a new hugepage_size filter to a running probe via sysfs,
it triggers the filter appending path here:
damon_commit_ctx() -> damon_commit_probes() -> damon_commit_filters()
When the new filter is appended, damon_new_filter() allocates memory with
kmalloc(), which does not zero-initialize the memory. The switch statement
then omits copying range_min and range_max for
DAMON_FILTER_TYPE_HUGEPAGE_SIZE, leaving them as uninitialized heap garbage.
This makes the hugepage_size filter unpredictable and could cause incorrect
memory pages to be filtered in or out. It also completely bypasses the
validation logic added for existing filters in damon_commit_filter().
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260913171133.102366-1-sj@kernel.org?part=2
next prev parent reply other threads:[~2026-09-13 17:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-13 17:11 [RFC PATCH 0/8] mm/damon: introduce hugepage_size probe filter SJ Park
2026-09-13 17:11 ` [RFC PATCH 1/8] mm/damon/api: introduce DAMON_FILTER_TYPE_HUGEPAGE_SIZE SJ Park
2026-09-13 17:22 ` sashiko-bot
2026-09-13 17:31 ` SJ Park
2026-09-13 17:40 ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 2/8] mm/damon/core: commit hugepage_size type damon filter SJ Park
2026-09-13 17:24 ` sashiko-bot [this message]
2026-09-13 17:33 ` SJ Park
2026-09-13 17:41 ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 3/8] mm/damon/ops-common: support hugepage_size damon filter matching SJ Park
2026-09-13 17:24 ` sashiko-bot
2026-09-13 17:35 ` SJ Park
2026-09-13 17:41 ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 4/8] mm/damon/sysfs: add min,max files under probe filter directory SJ Park
2026-09-13 17:16 ` sashiko-bot
2026-09-13 17:11 ` [RFC PATCH 5/8] mm/damon/sysfs: support hugepage_size probe filter SJ Park
2026-09-13 17:30 ` sashiko-bot
2026-09-13 17:38 ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 6/8] Docs/mm/damon/design: update for " SJ Park
2026-09-13 17:24 ` sashiko-bot
2026-09-13 17:42 ` SJ Park
2026-09-13 17:11 ` [RFC PATCH 7/8] Docs/admin-guide/mm/damon/usage: update for hugepage_size SJ Park
2026-09-13 17:13 ` sashiko-bot
2026-09-13 17:11 ` [RFC PATCH 8/8] Docs/ABI/damon: update for hugepage_size probe filter SJ Park
2026-09-13 17:13 ` sashiko-bot
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=20260913172422.3F7811F000FF@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.