Re: [RFC PATCH v1.2 14/19] mm/damon/core: get merge threshold from probe hits when weights are set

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Missing validation for `apply_probes` callback when probe weights are configured leads to complete DAMON region collapse.
--

--- Patch [14]: [RFC PATCH v1.2 14/19] mm/damon/core: get merge threshold from probe hits when weights are set ---
commit a4d0e22d5d4d741ec6086d8f49fefbab2c3b57bd
Author: SJ Park <sj@kernel.org>

mm/damon/core: get merge threshold from probe hits when weights are set

When probe weights are set, DAMON merges regions based on their probe
hits weighted sum.  But the merge threshold is calculated based on the
access frequency.  Update it to retrieve the maximum probe hits weighted
sum in the snapshot from apply_probes() ops callback, and generate the
threshold based on it.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 8837b2129baa6..12c66edecd783 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3776,9 +3777,18 @@ static int kdamond_fn(void *data)
>  
>  		if (!access_check_disabled && ctx->ops.check_accesses)
>  			max_merge_score = ctx->ops.check_accesses(ctx);
> -		if (ctx->ops.apply_probes)
> -			ctx->ops.apply_probes(ctx, access_check_disabled,
> -					false);
> +		if (ctx->ops.apply_probes) {
> +			if (time_after_eq(ctx->passed_sample_intervals,
> +						next_aggregation_sis) &&
> +					access_check_disabled)
> +				get_max_wsum = true;
> +			else
> +				get_max_wsum = false;
> +			max_wsum = ctx->ops.apply_probes(ctx,
> +					access_check_disabled, get_max_wsum);
> +			if (get_max_wsum)
> +				max_merge_score = max_wsum;
> +		}

[Severity: High]
If a configuration has probe weights enabled (so access_check_disabled is
true) but the active operations do not implement the apply_probes callback
(like vaddr or fvaddr), does max_merge_score remain 0 here?

It appears that skipping both check_accesses() and apply_probes() leaves
max_merge_score at 0. Later, when kdamond_merge_regions() is called with a
threshold of 0, and all regions have 0 probe hits, damon_merge_regions_of()
would see a difference of 0 between adjacent regions.

Could this lead to aggressive merging of all regions up to sz_limit,
effectively collapsing the fine-grained region layout?

Should there be a validation check in damon_valid_probe_params() to reject
configurations where probe weights are set but ctx->ops.apply_probes is
missing?

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