From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH 01/11] mm/damon/core: stop ctxs in damon_start() before returning an error
Date: Sat, 4 Jul 2026 11:40:03 -0700 [thread overview]
Message-ID: <20260704184004.133933-1-sj@kernel.org> (raw)
In-Reply-To: <20260704182050.5C01A1F000E9@smtp.kernel.org>
On Sat, 04 Jul 2026 18:20:49 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Calling damon_stop() from within damon_start() while holding damon_lock causes an AB-BA deadlock with kdamond_fn().
> --
>
> commit 1cec89c3cfde2c1ab34bcccb4767280aac126514
> Author: SJ Park <sj@kernel.org>
>
> mm/damon/core: stop ctxs in damon_start() before returning an error
>
> When multiple contexts are passed to damon_start(), it starts them one
> by one and returns an error immediately on failure. This commit adds logic
> to stop any already-started contexts directly within damon_start() if a
> subsequent context fails to start.
>
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index c6fc35be633b3..45aa9acef4e30 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -1836,8 +1836,10 @@ int damon_start(struct damon_ctx **ctxs, int nr_ctxs, bool exclusive)
> >
> > for (i = 0; i < nr_ctxs; i++) {
> > err = __damon_start(ctxs[i]);
> > - if (err)
> > + if (err) {
> > + damon_stop(ctxs, i);
>
> [Severity: High]
> Will this cause a deadlock if a context fails to start?
>
> damon_start() holds damon_lock while iterating through the contexts. When it
> encounters an error, it calls damon_stop() which synchronously waits for the
> previously started kthreads to stop.
>
> However, the kdamond_fn thread attempts to acquire the same damon_lock
> during its cleanup phase before it can exit:
>
> kdamond_fn() {
> ...
> mutex_lock(&damon_lock);
> nr_running_ctxs--;
> ...
> mutex_unlock(&damon_lock);
> }
>
> Since damon_start() is blocking on the thread exit while holding damon_lock,
> and the thread is blocking on damon_lock to exit, doesn't this result in a
> circular wait?
Good finding. I will fix this in the next revision by calling damon_stop()
after releasing the mutex, like below.
"""
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2182,16 +2182,17 @@ int damon_start(struct damon_ctx **ctxs, int nr_ctxs, bool exclusive)
for (i = 0; i < nr_ctxs; i++) {
err = __damon_start(ctxs[i]);
- if (err) {
- damon_stop(ctxs, i);
+ if (err)
break;
- }
nr_running_ctxs++;
}
if (exclusive && nr_running_ctxs)
running_exclusive_ctxs = true;
mutex_unlock(&damon_lock);
+ if (i != nr_ctxs)
+ damon_stop(ctxs, i);
+
return err;
}
"""
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-07-04 18:40 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-04 18:11 [RFC PATCH 00/11] mm/damon: refactor damon_{start,stop,commit}() for simple error handling SJ Park
2026-07-04 18:11 ` [RFC PATCH 01/11] mm/damon/core: stop ctxs in damon_start() before returning an error SJ Park
2026-07-04 18:20 ` sashiko-bot
2026-07-04 18:40 ` SJ Park [this message]
2026-07-04 18:11 ` [RFC PATCH 02/11] samples/damon/mtier: do not stop first context for damon_start() failure SJ Park
2026-07-04 18:24 ` sashiko-bot
2026-07-04 18:42 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 03/11] mm/damon/core: make damon_stop() never fails SJ Park
2026-07-04 18:30 ` sashiko-bot
2026-07-04 18:43 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 04/11] mm/damon/sysfs: ignore damon_stop() return value SJ Park
2026-07-04 18:11 ` [RFC PATCH 05/11] mm/damon/reclaaim: " SJ Park
2026-07-04 18:11 ` [RFC PATCH 06/11] mm/damon/lru_sort: " SJ Park
2026-07-04 18:11 ` [RFC PATCH 07/11] mm/damon/core: change damon_stop() return type to void SJ Park
2026-07-04 18:23 ` sashiko-bot
2026-07-04 19:36 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 08/11] samples/damon/mtier: stop all contexts with single damon_stop() call SJ Park
2026-07-04 18:20 ` sashiko-bot
2026-07-04 19:37 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 09/11] mm/damon/core: stop ctx in damon_call() before reruning an error SJ Park
2026-07-04 18:25 ` sashiko-bot
2026-07-04 19:34 ` SJ Park
2026-07-04 19:47 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 10/11] samples/damon/wsse: do not stop ctx for damon_call() failure SJ Park
2026-07-04 18:31 ` sashiko-bot
2026-07-04 19:38 ` SJ Park
2026-07-04 18:11 ` [RFC PATCH 11/11] samples/damon/prcl: do not stop DAMON " SJ Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260704184004.133933-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=damon@lists.linux.dev \
--cc=sashiko-bot@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.