Re: [RFC PATCH 10/11] samples/damon/wsse: do not stop ctx for damon_call() failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A self-deadlock occurs in `damon_start()` if a subsequent context fails to start.
--

commit 2f9c1f0eae64d458e95f8baff7b56262e634bb2f
Author: SJ Park <sj@kernel.org>

samples/damon/wsse: do not stop ctx for damon_call() failure

This commit modifies the error handling path in damon_sample_wsse_start()
when damon_call() fails. It removes the explicit call to damon_stop()
because damon_call() is updated to stop the context on its own.

> diff --git a/samples/damon/wsse.c b/samples/damon/wsse.c
> index ff5e8a890f448..37fd5da201588 100644
> --- a/samples/damon/wsse.c
> +++ b/samples/damon/wsse.c
> @@ -93,10 +93,8 @@ static int damon_sample_wsse_start(void)
>  	}
>  	repeat_call_control.data = ctx;
>  	err = damon_call(ctx, &repeat_call_control);
> -	if (err) {
> -		damon_stop(&ctx, 1);
> +	if (err)
>  		damon_destroy_ctx(ctx);
> -	}
>  	return err;
>  }

[Severity: High]
Does this code expose a self-deadlock in damon_start() if a context fails to
start?

When damon_sample_wsse_start() calls damon_start() earlier in the execution,
it iterates over the contexts and calls __damon_start() to spawn a kdamond
thread for each, all while holding damon_lock. If __damon_start() fails, the
error handling path calls damon_stop() to tear down the already-started
contexts:

mm/damon/core.c:damon_start() {
    ...
    mutex_lock(&damon_lock);
    ...
        err = __damon_start(ctxs[i]);
        if (err) {
            damon_stop(ctxs, i);
            break;
        }
    ...
}

damon_stop() internally calls __damon_stop(), which invokes kthread_stop_put()
to synchronously wait for the running kdamond thread to exit.

However, when the exiting kdamond thread finishes its main loop and cleans up,
it attempts to acquire damon_lock to decrement nr_running_ctxs:

mm/damon/core.c:kdamond_fn() {
    ...
    mutex_lock(&damon_lock);
    nr_running_ctxs--;
    if (!nr_running_ctxs && running_exclusive_ctxs)
        running_exclusive_ctxs = false;
    mutex_unlock(&damon_lock);
    ...
}

Because the original thread executing damon_start() is still holding
damon_lock while waiting for the kdamond thread to exit, can this result
in a permanent ABBA deadlock?

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