Re: [PATCH 04/18] mm/damon/core: handle unreset nr_accesses in damon_nr_accesses_mvsum()

[SJ Park <sj@kernel.org>]

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

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] damon_nr_accesses_mvsum() incorrectly returns stale data (r->last_nr_accesses) when damon_set_attrs() is called exactly at the end of an aggregation window.
> --
> 
> commit ebe6cc65ba2de465cab83d7ffe913bb9f8304f66
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: handle unreset nr_accesses in damon_nr_accesses_mvsum()
> 
> This commit adds logic to damon_nr_accesses_mvsum() to return
> last_nr_accesses when the remaining window is full. It aims to avoid
> unnecessarily counting unreset nr_accesses when damon_set_attrs() is
> called at the end of an aggregation window.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 94dd425ee4353..df79f4d10bdc3 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -266,6 +266,9 @@ unsigned int damon_nr_accesses_mvsum(struct damon_region *r,
> >  			ctx->passed_sample_intervals;
> >  	left_window_bp = mult_frac(left_window, 10000, window_len);
> >  
> > +	if (left_window_bp == 10000)
> > +		return r->last_nr_accesses;
> > +
> 
> [Severity: Medium]
> Will this early return cause the function to return stale data from the 
> previous window instead of freshly accumulated data?
> 
> If damon_set_attrs() is called at the end of an aggregation window,
> damon_update_monitoring_result() processes this with aggregating = false. 
> This intentionally preserves the fully accumulated r->nr_accesses for the
> newly completed window. 
> 
> After damon_set_attrs() pushes ctx->next_aggregation_sis forward, a
> subsequent call to damon_nr_accesses_mvsum() will calculate left_window_bp
> as 10000. 
> 
> Because of this early return, won't it discard the freshly accumulated 
> r->nr_accesses and incorrectly return the older r->last_nr_accesses instead?

Too minor issue to block this series, as I also previously replied [1].  I will
further work on improving this when I get a bandwidth.

[1] https://lore.kernel.org/20260623002313.35582-1-sj@kernel.org


Thanks,
SJ

[...]