Re: [RFC PATCH] mm/damon/stat: detect and use fresh enabled status

[SeongJae Park <sj@kernel.org>]

On Thu, 16 Apr 2026 07:38:55 -0700 SeongJae Park <sj@kernel.org> wrote:

> DAMON_STAT assumes the kdamond will keep running once damon_stat_start()
> succeeds, until it calls damon_stop() to stop it.  If the
> regions_score_histogram allocation in kdamond_fn() is tried after
> damon_stat_start() returns, however, and if the allocation fails, the
> kdamond can stop before DAMON_STAT calls damon_stop().  In this case,
> users will show the 'enabled' parameter value as 'true', while it is not
> working.  This could make users confused.
> 
> The user impact should be mild, though.  First of all, the issue may
> happen only quite rarely.  The allocation failure is arguably too small
> to fail (100 unsigned long objects) in common setups.  The time window
> for the race is also quite small.  Even if the race and the allocation
> failure happen, users could find the fact that the kdamond is stopped
> using 'ps' like commands.  By writing 'N' and 'Y' to the 'enabled'
> parameter sequentially, the user can also easily restart DAMON_STAT.
> 
> That said, the bug is a bug that needs to be fixed.  Instead of managing
> the complicated state in the variable, detect and use the real kdamond
> running status when the user reads the parameter, via the parameter read
> callback.  This will allow users to always read the correct 'enabled'
> value.
> 
> Note that the 'enabled' variable is no longer the argument for the
> 'enabled' parameter.  But it is still used for two use case.  For
> keeping the config/boot time user-set parameter value.  And for keeping
> the user request to compare against the current state, to see if the
> damon_start() or damon_stop() call are really needed.

Posted the next version of this patch as a part of another series [1], because
the patches of the series are fixing the similar type of bugs.

[1] https://lore.kernel.org/20260418014439.6353-1-sj@kernel.org


Thanks,
SJ

[...]