From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [RFC PATCH v2 1/3] mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values
Date: Sat, 18 Apr 2026 08:14:37 -0700 [thread overview]
Message-ID: <20260418151438.787-1-sj@kernel.org> (raw)
In-Reply-To: <20260418045715.EAF7EC2BCB5@smtp.kernel.org>
On Sat, 18 Apr 2026 04:57:15 +0000 sashiko-bot@kernel.org wrote:
> Sashiko AI review found 1 potential issue(s):
> - [Medium] Command-line override for the 'enabled' parameter is broken: passing 'enabled=N' after 'enabled=Y' fails to disable the module.
> --
>
> commit 6f46639cc34c6ddcbecc0aba915988dff8f651de
> Author: SeongJae Park <sj@kernel.org>
>
> mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values
>
> This commit updates DAMON_RECLAIM to dynamically query the running status
> of kdamond instead of relying on cached parameter values. This ensures
> that when kdamond stops unexpectedly, the enabled and kdamond_pid parameters
> reflect the correct state.
>
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index 86da147786583..46660c8d4d422 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
>
> [ ... ]
>
> > @@ -332,10 +316,16 @@ module_param_cb(addr_unit, &addr_unit_param_ops, &addr_unit, 0600);
> > MODULE_PARM_DESC(addr_unit,
> > "Scale factor for DAMON_RECLAIM to ops address conversion (default: 1)");
> >
> > +static bool damon_reclaim_enabled(void)
> > +{
> > + if (!ctx)
> > + return false;
> > + return damon_is_running(ctx);
> > +}
> > +
> > static int damon_reclaim_enabled_store(const char *val,
> > const struct kernel_param *kp)
> > {
> > - bool is_enabled = enabled;
> > bool enable;
> > int err;
> >
> > @@ -343,7 +333,7 @@ static int damon_reclaim_enabled_store(const char *val,
> > if (err)
> > return err;
> >
> > - if (is_enabled == enable)
> > + if (damon_reclaim_enabled() == enable)
> > return 0;
>
> Does changing this check break kernel command-line overrides during boot?
>
> During early boot when command-line parameters are parsed, ctx is not yet
> allocated, so damon_reclaim_enabled() unconditionally returns false.
>
> If a system has damon_reclaim.enabled=Y in the boot parameters and an
> administrator appends damon_reclaim.enabled=N to override it, the first
> evaluation correctly sets the internal enabled flag to true.
>
> However, when the second parameter (N) is processed, enable is false.
> Since damon_reclaim_enabled() also returns false, the condition matches
> and the function returns 0 immediately. The internal enabled variable is
> never updated to false, causing the module to start unexpectedly when
> damon_reclaim_init() runs.
>
> Should this keep checking the internal enabled variable during early boot?
I don't think such override is common, but I also think there is no harm at
making the old behavior be kept. I will address this like below, in the next
revision.
'''
--- a/mm/damon/reclaim.c
+++ b/mm/damon/reclaim.c
@@ -381,27 +381,20 @@ static bool damon_reclaim_enabled(void)
static int damon_reclaim_enabled_store(const char *val,
const struct kernel_param *kp)
{
- bool enable;
int err;
- err = kstrtobool(val, &enable);
+ err = kstrtobool(val, &enabled);
if (err)
return err;
- if (damon_reclaim_enabled() == enable)
+ if (damon_reclaim_enabled() == enabled)
return 0;
/* Called before init function. The function will handle this. */
if (!damon_initialized())
- goto set_param_out;
-
- err = damon_reclaim_turn(enable);
- if (err)
- return err;
+ return 0;
-set_param_out:
- enabled = enable;
- return err;
+ return damon_reclaim_turn(enabled);
}
static int damon_reclaim_enabled_load(char *buffer,
'''
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-04-18 15:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 1:44 [RFC PATCH v2 0/3] mm/damon/modules: detect and use fresh status SeongJae Park
2026-04-18 1:44 ` [RFC PATCH v2 1/3] mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values SeongJae Park
2026-04-18 4:57 ` sashiko-bot
2026-04-18 15:14 ` SeongJae Park [this message]
2026-04-18 1:44 ` [RFC PATCH v2 2/3] mm/damon/lru_sort: " SeongJae Park
2026-04-18 5:30 ` sashiko-bot
2026-04-18 15:36 ` SeongJae Park
2026-04-18 1:44 ` [RFC PATCH v2 3/3] mm/damon/stat: detect and use fresh enabled value SeongJae Park
2026-04-18 5:54 ` sashiko-bot
2026-04-18 15:40 ` 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=20260418151438.787-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.