From: SeongJae Park <sj@kernel.org>
To: SeongJae Park <sj@kernel.org>
Cc: Liew Rui Yan <aethernet65535@gmail.com>,
damon@lists.linux.dev, linux-mm@kvack.org
Subject: Re: (Sashiko) Re: [RFC v2] mm/damon: add synchronous validation for commit_inputs
Date: Sat, 21 Mar 2026 10:40:01 -0700 [thread overview]
Message-ID: <20260321174002.85141-1-sj@kernel.org> (raw)
In-Reply-To: <20260321170623.84638-1-sj@kernel.org>
On Sat, 21 Mar 2026 10:06:22 -0700 SeongJae Park <sj@kernel.org> wrote:
> Forwarding Sashiko review for doing the discussion on the mailing list.
>
> # review url: https://sashiko.dev/#/patchset/20260321140926.22163-1-aethernet65535@gmail.com
> # start of sashiko.dev inline review
> commit 05e8b12e4fe302bfaf2b30ee9c0d38b036fc1c5e
> Author: Liew Rui Yan <aethernet65535@gmail.com>
> Subject: mm/damon: add synchronous validation for commit_inputs
>
> This commit adds synchronous validation to the sysfs commit_inputs parameter
> for the DAMON lru_sort and reclaim modules. It aims to return immediate
> feedback to userspace if the provided monitoring attributes are invalid,
> rather than failing silently in the background.
>
> Link: https://lore.kernel.org/20260318153731.97470-1-aethernet65535@gmail.com
>
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > index db6c67e52d2b..22136486e745 100644
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -751,6 +751,27 @@ static bool damon_valid_intervals_goal(struct damon_attrs *attrs)
> > return true;
> > }
> >
> > +/**
> > + * damon_validate_attrs() - Check if the given DAMON attributes are valid.
> > + * @attrs: attributes to be checked
> > + *
> > + * Return: 0 if valid, negative error code otherwise.
> > + */
> > +int damon_validate_attrs(struct damon_attrs *attrs)
> > +{
> > + if (!damon_valid_intervals_goal(attrs))
> > + return -EINVAL;
> > + if (attrs->min_nr_regions < 3)
> > + return -EINVAL;
> > + if (attrs->min_nr_regions > attrs->max_nr_regions)
> > + return -EINVAL;
> > + if (attrs->sample_interval > attrs->aggr_interval)
> > + return -EINVAL;
>
> Does this validation fully prevent silent asynchronous failures?
>
> If a user writes 0 to sample_interval or aggr_interval, the check
> attrs->sample_interval > attrs->aggr_interval will pass (since 0 > 0 is
> false), returning success to the shell.
>
> Since the daemon's actual application logic requires non-zero intervals,
> will this still fail silently in the background for zero values?
Zero sample_interval and aggr_interval are valid DAMON parameters. DAMON logic
is written to allow that. If not, that's a bug or wrong design. Please let me
know if you find that. So this should be fine.
>
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL(damon_validate_attrs);
>
> Is this EXPORT_SYMBOL() necessary?
>
> Since both DAMON_RECLAIM and DAMON_LRU_SORT are built into the kernel and
> cannot be compiled as loadable modules, does this need to be exported to the
> global symbol table? None of the other DAMON core functions in this file
> appear to be exported for this reason.
I don't think it is necessary. I also suggested to just not expose this
function to in-kernel DAMON core API callers in the high level review.
>
> [ ... ]
> > diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> > index 554559d72976..883860721d3b 100644
> > --- a/mm/damon/lru_sort.c
> > +++ b/mm/damon/lru_sort.c
> [ ... ]
> > @@ -361,6 +360,39 @@ static int damon_lru_sort_handle_commit_inputs(void)
> > return err;
> > }
> >
> > +static int damon_lru_sort_commit_inputs_store(const char *val,
> > + const struct kernel_param *kp)
> > +{
> > + struct damon_attrs attrs;
> > + bool yes;
> > + int err;
> > +
> > + err = kstrtobool(val, &yes);
> > + if (err)
> > + return err;
> > +
> > + if (commit_inputs == yes)
> > + return 0;
> > +
> > + if (!yes)
> > + return 0;
>
> If a user writes 'N' to the sysfs parameter, yes evaluates to false and this
> returns success without updating commit_inputs.
>
> If commit_inputs was previously 'Y' (waiting for kdamond to process it),
> does this prevent administrators from aborting a pending parameter commit?
>
> > +
> > + attrs = damon_lru_sort_mon_attrs;
> > + err = damon_validate_attrs(&attrs);
>
> Will this synchronous validation reject valid configurations if
> autotune_monitoring_intervals is enabled?
>
> The actual parameter application logic in damon_lru_sort_apply_parameters()
> overwrites sample_interval and aggr_interval with hardcoded defaults when
> autotuning is on.
>
> Because this validation happens before those overrides are applied, will a
> user who leaves sample_interval > aggr_interval receive a false -EINVAL error
> even though the configuration would be safely overridden?
I haven't think thoroughly about this. But I think synchronously doing not
only validation but also commit, as I suggested on the high level review will
solve these complex problems.
>
> > + if (err)
> > + return err;
> > +
> > + commit_inputs = yes;
> > + return err;
> > +}
> [ ... ]
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index 86da14778658..6ea44b02cc76 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> [ ... ]
> > @@ -267,6 +266,39 @@ static int damon_reclaim_handle_commit_inputs(void)
> > return err;
> > }
> >
> > +static int damon_reclaim_commit_inputs_store(const char *val,
> > + const struct kernel_param *kp)
> > +{
> > + struct damon_attrs attrs;
> > + bool yes;
> > + int err;
> > +
> > + err = kstrtobool(val, &yes);
> > + if (err)
> > + return err;
> > +
> > + if (commit_inputs == yes)
> > + return 0;
> > +
> > + if (!yes)
> > + return 0;
>
> Similar to the lru_sort module, does returning 0 here without clearing
> commit_inputs prevent users from aborting a pending commit by writing 'N'?
Again, I believe doing both validation and commit synchronously will eliminate
these complexity.
>
> > +
> > + attrs = damon_reclaim_mon_attrs;
> > + err = damon_validate_attrs(&attrs);
> > + if (err)
> > + return err;
> > +
> > + commit_inputs = yes;
> > + return err;
> > +}
> [ ... ]
>
>
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260321140926.22163-1-aethernet65535@gmail.com
FYI,
hkml [1] generated a draft of this mail using below command:
hkml patch sashiko_dev --for_forwarding 20260321140926.22163-1-aethernet65535@gmail.com
[1] https://github.com/sjp38/hackermail
Thanks,
SJ
next prev parent reply other threads:[~2026-03-21 17:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-21 14:09 [RFC v2] mm/damon: add synchronous validation for commit_inputs Liew Rui Yan
2026-03-21 17:06 ` (Sashiko) " SeongJae Park
2026-03-21 17:40 ` SeongJae Park [this message]
2026-03-21 17:32 ` SeongJae Park
2026-03-22 6:06 ` Liew Rui Yan
2026-03-22 15:37 ` 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=20260321174002.85141-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=aethernet65535@gmail.com \
--cc=damon@lists.linux.dev \
--cc=linux-mm@kvack.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.