Re: [RFC PATCH v2 3/3] mm/damon/stat: detect and use fresh enabled value

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [Medium] Leaking damon_stat_context when explicitly disabling DAMON_STAT after an unexpected kdamond termination.
--

commit 4bf999258ec2f00a1ac02dbd77ac9f923e38bd2f
Author: SeongJae Park <sj@kernel.org>

mm/damon/stat: detect and use fresh enabled value

This commit modifies DAMON_STAT to dynamically check the kdamond status
when the enabled parameter is requested, rather than relying on a cached
parameter value. This ensures users do not see stale values if kdamond
stops unexpectedly.

> diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> index 99ba346f9e325..3951b762cbddf 100644
> --- a/mm/damon/stat.c
> +++ b/mm/damon/stat.c
[ ... ]
> @@ -273,17 +276,23 @@ static void damon_stat_stop(void)
>  	damon_stat_context = NULL;
>  }
>  
> +static bool damon_stat_enabled(void)
> +{
> +	if (!damon_stat_context)
> +		return false;
> +	return damon_is_running(damon_stat_context);
> +}
> +
>  static int damon_stat_enabled_store(
>  		const char *val, const struct kernel_param *kp)
>  {
> -	bool is_enabled = enabled;
>  	int err;
>  
>  	err = kstrtobool(val, &enabled);
>  	if (err)
>  		return err;
>  
> -	if (is_enabled == enabled)
> +	if (damon_stat_enabled() == enabled)
>  		return 0;

Could this leak damon_stat_context if the kdamond thread stops unexpectedly?

If kdamond terminates due to an internal failure,
damon_is_running(damon_stat_context) returns false, making
damon_stat_enabled() also return false.

If a user then explicitly disables DAMON_STAT by writing 'N' to the enabled
parameter, both damon_stat_enabled() and enabled would be false. This causes
the function to return 0 early, bypassing the call to damon_stat_stop().

Since damon_stat_stop() is the function responsible for invoking
damon_destroy_ctx() and setting damon_stat_context to NULL, does this bypass
leave the context structure allocated?

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