From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [RFC PATCH v1.1 7/8] mm/damon/core: remove start, end check in damon_set_region_system_rams()
Date: Thu, 02 Jul 2026 21:16:52 +0000 [thread overview]
Message-ID: <20260702211652.A17B51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260702210551.95167-8-sj@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing the explicit `*start > *end` check introduces inconsistent input validation, allowing inverted or zero-size ranges to be silently accepted.
--
commit ad7c7a8a7766992d5ad4dbe1c23874e807f45071
Author: SJ Park <sj@kernel.org>
mm/damon/core: remove start, end check in damon_set_region_system_rams()
damon_set_region_system_rams() validates user inputs to avoid creating a
negative size region. But DAMON core avoids zero size, too. The check
is incomplete. The complete check is done inside damon_set_regions(),
which is eventually called from damon_set_region_system_rams_default().
Drop the incomplete and unnecessary check.
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 179ce6b0a542d..dba53a41a1025 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -3812,9 +3812,6 @@ int damon_set_region_system_rams_default(struct damon_target *t,
> {
> struct damon_addr_range addr_range;
>
> - if (*start > *end)
> - return -EINVAL;
> -
[Severity: Medium]
Does removing this check allow invalid inverted or zero-size unaligned bounds
to be silently accepted?
The commit message claims that a complete check is done inside
damon_set_regions(). However, looking at damon_set_regions(), the validation
acts on aligned values:
mm/damon/core.c:damon_set_regions() {
...
for (i = 0; i < nr_ranges; i++) {
if (ALIGN_DOWN(ranges[i].start, min_region_sz) >=
ALIGN(ranges[i].end, min_region_sz))
return -EINVAL;
}
...
}
If unaligned invalid bounds are passed (for example, start=4095 and end=20,
or start=20 and end=20), they are rounded to valid blocks (e.g., 0 to 4096)
by ALIGN_DOWN and ALIGN.
Because they evaluate to a valid positive range after alignment, they escape
the >= check and are silently accepted.
Should this explicit check be kept to ensure unaligned invalid bounds are
correctly rejected before alignment?
> if (!*start && !*end &&
> !damon_find_system_rams_range(start, end, addr_unit))
> return -EINVAL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702210551.95167-1-sj@kernel.org?part=7
next prev parent reply other threads:[~2026-07-02 21:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-02 21:05 [RFC PATCH v1.1 0/8] mm/damon: validate all parameters in the core SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 1/8] mm/damon/core: safely validate src on damon_commit_ctx() SJ Park
2026-07-02 21:21 ` sashiko-bot
2026-07-02 21:35 ` SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 2/8] mm/damon/core: do parameter testing commit on damon_start() SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 3/8] mm/damon/sysfs: remove duplicated commit input validity check SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 4/8] mm/damon/reclaim: remove duplicated min_region_sz power of 2 check SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 5/8] mm/damon/lru_sort: remove duplicated min_region_sz power_of_2() check SJ Park
2026-07-02 21:20 ` sashiko-bot
2026-07-02 21:44 ` SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 6/8] mm/damon: document region size validation in damon_set_regions() SJ Park
2026-07-02 21:19 ` sashiko-bot
2026-07-02 21:48 ` SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 7/8] mm/damon/core: remove start, end check in damon_set_region_system_rams() SJ Park
2026-07-02 21:16 ` sashiko-bot [this message]
2026-07-02 21:50 ` SJ Park
2026-07-02 21:05 ` [RFC PATCH v1.1 8/8] mm/damon/sysfs: remove region size validation SJ Park
2026-07-02 21:15 ` sashiko-bot
2026-07-02 21:53 ` 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=20260702211652.A17B51F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox