Re: [PATCH 12/19] mm/damon/core: set samples in apply_probes() if probe weights are set

[SJ Park <sj@kernel.org>]

On Fri, 10 Jul 2026 14:02:54 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] kdamond_merge_regions() uses a stale or 0 threshold (max_nr_accesses) when probe weights are set, preventing proper region merging.
> --
> 
> --- Patch [12]: [PATCH 12/19] mm/damon/core: set samples in apply_probes() if probe weights are set ---
> commit c57b42d6ad5d1b962d67f040aa171492d081c859
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/core: set samples in apply_probes() if probe weights are set
> 
> When probe weights are set, the prepare_access_checks() ops callback is
> not invoked, so sampling addresses of regions are unset. Ask apply_probes()
> to set those together in the case.
> 
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index 65f91e3b58d2e..dd0612e1a408b 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -3777,7 +3777,8 @@ static int kdamond_fn(void *data)
> >  		if (!access_check_disabled && ctx->ops.check_accesses)
> >  			max_nr_accesses = ctx->ops.check_accesses(ctx);
> >  		if (ctx->ops.apply_probes)
> > -			ctx->ops.apply_probes(ctx, false, false);
> > +			ctx->ops.apply_probes(ctx, access_check_disabled,
> > +					false);
> >  
> >  		if (time_after_eq(ctx->passed_sample_intervals,
> >  					next_aggregation_sis)) {
> 
> [Severity: Medium]
> When access_check_disabled is true, ctx->ops.check_accesses() is skipped.
> Does this leave max_nr_accesses stale or set to 0 when it is subsequently
> passed to kdamond_merge_regions() shortly after this block?
> 
> If max_nr_accesses evaluates to 0, it seems this might defeat the 10 percent
> tolerance logic for region aggregation.
> 
> Could this force adjacent regions to merge only when their scores match
> exactly, leading to region fragmentation until the maximum region limit
> is hit?
> 
> Since damon_has_probe_weights() currently returns false unconditionally
> to safely stage the new feature, this appears to be unreachable today, but
> might become a regression once the feature is fully enabled.

No issue.  access_check_disabled is always false at this moment.  A later patch
in this series will avoid the issue before it can be true.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260710134651.18084-1-sj@kernel.org?part=12


Thanks,
SJ