Re: [RFC PATCH] mm/damon: reset thread status parameters upon kdamond termination

[Liew Rui Yan <aethernet65535@gmail.com>]

Hi SeongJae,

On Wed,  1 Apr 2026 08:41:18 -0700 SeongJae Park <sj@kernel.org> wrote:

> [...]
> What about checking if damon_call() and damon_commit_ctx() failures via therir
> return value?  It seems damon_call() fails only when kdamond goes to the
> termination path.  damon_commit_ctx() failure always causes the kdamond be
> terminated.  So if I didn't miss something that could be a path forward.  What
> do you think?

Thank you for the suggestion. I looked into the code and I think
focusing on damon_commit_ctx() failures makes sense.

Specifically, damon_call() is only used in the damon_{lru_sort, reclaim}
_enabled_store() path, which doesn't trigger unexpected termination. The
main risk comes from 'commit_inputs', which calls damon_{lru_sort,
reclaim}_apply_parameters() . When damon_commit_ctx() fails there, it
reliably indicates that kdamond is terminating.

My plan is to add the error check directly in apply_parameters(), right
after damon_commit_ctx():

    err = damon_commit_ctx(ctx, param_ctx);
    if (err) {
        enabled = false;
        kdamond_pid = -1;
    }

This covers the reproducible case (addr_unit=3 + commit_inputs=Y).

For truly unexpected termination (e.g., memory allocation failure inside
kdamond), I'm considering a fallback mechanism in enabled_store():

- When the user writes 'N' to 'enabled', if damon_stop() fails but
  kdamond is actually terminated, we reset enabled and kdamond_pid.

- When the user writes 'Y' to 'enabled', if enabled is already 'Y' but
  kdamond is terminated, we treat this as a restart request.

This way, even if kdamond terminates unexpectedly, the next user
interaction will recover the state automatically.

Does this approach sound reasonable?

Best regards,
Rui Yan