Re: [RFC PATCH 08/11] samples/damon/mtier: stop all contexts with single damon_stop() call

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] AB-BA deadlock in `damon_start()` error path with `kdamond_fn` over `damon_lock`.
--

commit 65a3f2350afc5895953b74d531916747653f71ed
Author: SJ Park <sj@kernel.org>

samples/damon/mtier: stop all contexts with single damon_stop() call

damon_stop() was theoretically able to return failure while keeping the
second context for mtier running.  mtier stops its contexts one by one
with two damon_stop() call for the reason.  damon_stop() is refactored
to always successfully stop all requested DAMON contexts.  The two calls
are unnecessary.  Use only single damon_stop() call for all contexts.

> diff --git a/samples/damon/mtier.c b/samples/damon/mtier.c
> index 90881e8bd441f..ac9c24b92ead8 100644
> --- a/samples/damon/mtier.c
> +++ b/samples/damon/mtier.c
> @@ -200,8 +200,7 @@ static int damon_sample_mtier_start(void)
>  
>  static void damon_sample_mtier_stop(void)
>  {
> -	damon_stop(ctxs, 1);
> -	damon_stop(&ctxs[1], 1);
> +	damon_stop(ctxs, 2);

[Severity: High]
This bug was introduced in this series by commit "mm/damon/core: stop ctxs
in damon_start() before returning an error" and remains unfixed at the end
of the series.

Does the error path in damon_start() introduce an AB-BA deadlock with
kdamond_fn() over damon_lock?

If a caller attempts to start multiple DAMON contexts and damon_start()
successfully starts at least one context but fails on a subsequent one,
it calls damon_stop() while still holding damon_lock:

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

damon_stop() synchronously waits for the kdamond thread to exit. However,
the kdamond thread blocks forever waiting 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);
}

Could this permanent deadlock hang the kdamond kernel thread and any process
attempting to use DAMON?

>  	damon_destroy_ctx(ctxs[0]);
>  	damon_destroy_ctx(ctxs[1]);
>  }

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