Re: [PATCH] mm/damon: reject zero sampling interval

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mm: obsolete zero-interval fallbacks left in core.c
--

commit 3fc9c7e0ec1f59dfad336e3842553089ded8b3b8
Author: Karthikeyan KS <karthiproffesional@gmail.com>

mm/damon: reject zero sampling interval

damon_set_attrs() already rejects inverted intervals, but it accepts
sample_interval == 0. A zero sampling interval is not a valid monitoring
period and causes busy-spinning in kdamond. Return -EINVAL if
sample_interval is zero.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 444c97c184027..7faa92106cf1d 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -1135,6 +1135,8 @@ int damon_set_attrs(struct damon_ctx *ctx, struct damon_attrs *attrs)
>  		return -EINVAL;
>  	if (attrs->min_nr_regions > attrs->max_nr_regions)
>  		return -EINVAL;
> +	if (!attrs->sample_interval)
> +		return -EINVAL;

[Severity: Low]
Since attrs->sample_interval and attrs->aggr_interval are now explicitly
rejected if zero, do we still need the zero-interval fallbacks scattered
throughout core.c?

For example, earlier in damon_set_attrs() we have:

	unsigned long sample_interval = attrs->sample_interval ?
		attrs->sample_interval : 1;

And similarly in kdamond_init_ctx() and kdamond_fn():

	sample_interval = ctx->attrs.sample_interval ?
		ctx->attrs.sample_interval : 1;

There is also a defensive check in damon_update_monitoring_results() that
looks obsolete now:

	if (!old_attrs->sample_interval || !old_attrs->aggr_interval ||
			!new_attrs->sample_interval ||
			!new_attrs->aggr_interval)
		return;

Should we clean up these zero-interval fallbacks since they appear to be
structurally unreachable after this change?

>  	if (attrs->sample_interval > attrs->aggr_interval)
>  		return -EINVAL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260917150631.1138698-1-karthiproffesional@gmail.com?part=1