Re: [RFC PATCH v1.1 7/8] mm/damon/core: remove start, end check in damon_set_region_system_rams()

[SJ Park <sj@kernel.org>]

On Thu, 02 Jul 2026 21:16:52 +0000 sashiko-bot@kernel.org wrote:

> 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?

Both are no issues.  Refer to my reply to patch 6 Sashiko reply for more
details.


Thanks,
SJ

[...]