Re: [RFC PATCH 02/11] samples/damon/mtier: do not stop first context for damon_start() failure

[SJ Park <sj@kernel.org>]

On Sat, 04 Jul 2026 18:24:05 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] ABBA deadlock in damon_start() during error recovery when rolling back successfully started contexts.
> --
> 
> commit c411cd45182c74c483bd6bd5d58aea28123f720d
> Author: SJ Park <sj@kernel.org>
> 
> samples/damon/mtier: do not stop first context for damon_start() failure
> 
> damon_start() was able to fail while keeping the first context running.
> mtier hence stops the first context in the case. damon_start() is
> refactored to avoid that. The error handling is no longer necessary.
> Remove it.
> 
> > diff --git a/samples/damon/mtier.c b/samples/damon/mtier.c
> > index e567f4edd80ea..90881e8bd441f 100644
> > --- a/samples/damon/mtier.c
> > +++ b/samples/damon/mtier.c
> > @@ -193,8 +193,6 @@ static int damon_sample_mtier_start(void)
> >  	if (!err)
> >  		return 0;
> >  
> > -	if (damon_is_running(ctxs[0]))
> > -		damon_stop(ctxs, 1);
> 
> [Severity: High]
> Does the refactored error handling in damon_start() introduce a deadlock?
> 
> Since damon_start() is called with nr_ctxs = 2 here, if the first context
> starts successfully but the second one fails, the error recovery path in
> damon_start() could trigger an ABBA deadlock.
> 
> If damon_start() calls damon_stop() on the error path while holding
> damon_lock:
> 
> mm/damon/core.c:damon_start() {
>     ...
> 		err = __damon_start(ctxs[i]);
> 		if (err) {
> 			damon_stop(ctxs, i);
> 			break;
> 		}
>     ...
> }
> 
> damon_stop() blocks until the kdamond_fn() thread exits. However, kdamond_fn()
> attempts to acquire damon_lock at its exit path:
> 
> 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 cause kdamond_fn() to hang waiting for damon_lock, which is still
> held by damon_start(), resulting in a deadlock?

Yes, I will fix damon_start() it in the next revision.


Thanks,
SJ

[...]