From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: sashiko-bot@kernel.org, damon@lists.linux.dev
Subject: Re: [RFC PATCH v1.2 1/2] mm/damon/stat: add a parameter for reading kdamond pid
Date: Wed, 15 Apr 2026 21:06:01 -0700 [thread overview]
Message-ID: <20260416040602.88665-1-sj@kernel.org> (raw)
In-Reply-To: <20260416033546.87941-1-sj@kernel.org>
On Wed, 15 Apr 2026 20:35:45 -0700 SeongJae Park <sj@kernel.org> wrote:
> TL; DR: Sashiko found good point. I will fix it in the next revision.
>
> On Thu, 16 Apr 2026 00:59:35 +0000 sashiko-bot@kernel.org wrote:
>
> > Sashiko AI review found 1 potential issue(s):
> > - [Medium] Stale `kdamond_pid` exposed to userspace if `damon_call()` fails during startup.
> > --
> >
> > commit 46eb0a4278ccd2dec190db28b78b0766b8865901
> > Author: SeongJae Park <sj@kernel.org>
> >
> > mm/damon/stat: add a parameter for reading kdamond pid
> >
> > This commit exposes the pid of the DAMON_STAT kdamond via a new read-only
> > module parameter named kdamond_pid, standardizing usage with other DAMON
> > modules.
> >
> > > diff --git a/mm/damon/stat.c b/mm/damon/stat.c
> > > index 99ba346f9e325..4901e9a7c3398 100644
> > > --- a/mm/damon/stat.c
> > > +++ b/mm/damon/stat.c
> >
> > [ ... ]
> >
> > > @@ -260,6 +269,14 @@ static int damon_stat_start(void)
> > > damon_stat_context = NULL;
> > > return err;
> > > }
> > > + kdamond_pid = damon_kdamond_pid(damon_stat_context);
> > > + if (kdamond_pid < 0) {
> > > + err = kdamond_pid;
> > > + kdamond_pid = -1;
> > > + damon_destroy_ctx(damon_stat_context);
> > > + damon_stat_context = NULL;
> > > + return err;
> > > + }
> > >
> > > damon_stat_last_refresh_jiffies = jiffies;
> > > call_control.data = damon_stat_context;
> >
> > If damon_call() fails right after this and returns an error,
> > damon_stat_start() will pass that error back to its caller and the module
> > will revert to a disabled state.
> >
> > Does this leave a stale kdamond_pid exposed to userspace? The newly added
> > documentation states: "If DAMON_STAT is enabled, this becomes the PID of
> > the worker thread. Else, -1." Since the initialization fails, the module
> > remains disabled, but kdamond_pid isn't reset to -1 on this error path.
>
> Nice catch. I will do the kdamond_pid setup after damon_call() success, like
> below.
Wait... The same question was also raised [1] by Sashiko on the previous
version. And I was wrongly saying it is not this patch's fault. That was
completely wrong.
And the kdamond can stop even after the damon_kdamond_pid() call, if the
region_store_histogram allocation fails. In the case, kdamond_pid will again
be stale. 'enabled' parameter value will also be stale in the case. The worst
part of it is that in the case, DAMON_STAT cannot be restarted before the
system is reboot. The bug is similar to the one [2] that Liew found and
working on.
I will hold this patch and fix the bug first.
> Also, I will remove the damon_stat_context deallocation and unset when
> damon_kdamond_pid() failure, because it will be deallocated when
> damon_stat_start() is called again.
This also means my reply [1] to Sashiko's question about the damon_stat_context
leak on the previous version was wrong. I was saying it is indeed a bug, but
it was not.
[1] https://lore.kernel.org/20260414053742.90296-1-sj@kernel.org
[2] https://lore.kernel.org/20260415235529.86329-1-sj@kernel.org
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-04-16 4:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 0:21 [RFC PATCH v1.2 0/2] mm/damon/stat: add kdamond_pid parameter SeongJae Park
2026-04-16 0:21 ` [RFC PATCH v1.2 1/2] mm/damon/stat: add a parameter for reading kdamond pid SeongJae Park
2026-04-16 0:59 ` sashiko-bot
2026-04-16 3:35 ` SeongJae Park
2026-04-16 4:06 ` SeongJae Park [this message]
2026-04-16 4:29 ` SeongJae Park
2026-04-16 0:21 ` [RFC PATCH v1.2 2/2] Docs/admin-guide/mm/damon/stat: document kdamond_pid parameter SeongJae 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=20260416040602.88665-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.