Re: [PATCH 05/18] mm/damon/core: use damon_nr_accesses_mvsum() in __damos_valid_target()

[SJ Park <sj@kernel.org>]

On Tue, 30 Jun 2026 04:25:40 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] 32-bit integer overflow in `damon_nr_accesses_mvsum()` when calculating `left_window_bp` via `mult_frac()`.
> --
> 
> commit 73c4d41e08fa85ce70e1cc04b1dee325a553e44e
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: use damon_nr_accesses_mvsum() in __damos_valid_target()
> 
> This commit replaces the direct read of nr_accesses_bp with a call to
> damon_nr_accesses_mvsum() in __damos_valid_target(). This calculates the
> access score dynamically to be more tolerant to errors.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index df79f4d10bdc3..50939c3359bf7 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> [ ... ]
> > @@ -2126,10 +2126,11 @@ static noinline_for_stack void kdamond_tune_intervals(struct damon_ctx *c)
> >  	damon_set_attrs(c, &new_attrs);
> >  }
> >  
> > -static bool __damos_valid_target(struct damon_region *r, struct damos *s)
> > +static bool __damos_valid_target(struct damon_region *r, struct damos *s,
> > +		struct damon_ctx *c)
> >  {
> >  	unsigned long sz;
> > -	unsigned int nr_accesses = r->nr_accesses_bp / 10000;
> > +	unsigned int nr_accesses = damon_nr_accesses_mvsum(r, c);
> 
> [Severity: Medium]
> Does wiring up damon_nr_accesses_mvsum() to the active DAMOS region filtering
> path expose a 32-bit integer overflow?
> 
> Inside damon_nr_accesses_mvsum(), the calculation of left_window_bp uses
> the mult_frac() macro:
> 
> left_window_bp = mult_frac(left_window, 10000, window_len);
> 
> If a user or auto-tuning configures an aggr_interval / sample_interval ratio
> greater than ~429,496 (for example, an aggr_interval of 5,000,000 us and a
> sample_interval of 10 us), the intermediate multiplication inside mult_frac()
> can exceed the maximum 32-bit unsigned long value on 32-bit architectures:
> 
> (left_window % window_len) * 10000
> 
> This truncation would result in a severely deflated left_window_bp, leading
> to incorrect moving sum access scores. 
> 
> Could this cause DAMOS schemes to evaluate targets improperly, leading to 
> sub-optimal memory reclaim or migration decisions?

Known low priority issue.  Not a blocker for this patch.


Thanks,
SJ

[...]