Re: [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] kdamond_wait_activation() traps kdamond in an infinite sleep loop when no schemes are registered, completely breaking pure access monitoring.
--

--- Patch [2]: [PATCH 2/2] mm/damon: skip deactivated schemes in watermark checks and add fallback sleep ---
commit 7f4aa250c9a91aca4f1a7a02df1c14e1ab990d4e
Author: Liew Rui Yan <[email protected]>

mm/damon: skip deactivated schemes in watermark checks and add fallback sleep

This commit modifies scheme evaluation to skip those deactivated either by
watermarks or max_nr_snapshots. It also changes kdamond_wait_activation()
to sleep for the sample interval as a fallback when all schemes are
deactivated.

> diff --git a/mm/damon/core.c b/mm/damon/core.c
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c

[ ... ]

> @@ -3704,16 +3711,23 @@ static int kdamond_wait_activation(struct damon_ctx *ctx)
>  
>  	while (!kdamond_need_stop(ctx)) {
>  		damon_for_each_scheme(s, ctx) {
> +			if (s->max_nr_snapshots &&
> +				s->max_nr_snapshots <= s->stat.nr_snapshots)
> +				continue;
> +
>  			wait_time = damos_wmark_wait_us(s);
>  			if (!init_wait_time || wait_time < min_wait_time) {
>  				init_wait_time = true;
>  				min_wait_time = wait_time;
>  			}
>  		}
> -		if (!min_wait_time)
> +		if (!min_wait_time && init_wait_time)
>  			return 0;
>  
> -		kdamond_usleep(min_wait_time);
> +		if (min_wait_time)
> +			kdamond_usleep(min_wait_time);
> +		else
> +			kdamond_usleep(ctx->attrs.sample_interval);

[Severity: High]
Does this change cause a regression where kdamond becomes trapped in an
infinite sleep loop if no schemes are configured?

When a user starts DAMON for pure access monitoring without configuring any
schemes, the damon_for_each_scheme() loop is bypassed. This leaves
init_wait_time as false.

Because init_wait_time is false, the condition
if (!min_wait_time && init_wait_time) will fail. The function then falls
through to the new fallback logic:

    kdamond_usleep(ctx->attrs.sample_interval);

Since init_wait_time remains false on every iteration of the while loop,
kdamond_wait_activation() will never return 0. Could this permanently hang
the monitoring thread and prevent it from collecting any access metrics?

>  
>  		kdamond_call(ctx, false);
>  		if (ctx->maybe_corrupted)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2