All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [PATCH v2 3/4] mm/damon: add synchronous commit for commit_inputs
Date: Mon, 27 Apr 2026 07:30:50 -0700	[thread overview]
Message-ID: <20260427143052.111666-1-sj@kernel.org> (raw)
In-Reply-To: <20260427000012.7E772C2BCAF@smtp.kernel.org>

On Mon, 27 Apr 2026 00:00:11 +0000 sashiko-bot@kernel.org wrote:

> Sashiko AI review found 1 potential issue(s):
> - [High] Writing to the `commit_inputs` sysfs parameter before the DAMON worker thread (`kdamond`) is started causes the writing task to hang indefinitely in an unkillable D-state.

I think this is wrong.

> --
> 
> commit 43a70e5ab295c21c0b94eddd32d886c9d0eba3fa
> Author: Liew Rui Yan <aethernet65535@gmail.com>
> 
> mm/damon: add synchronous commit for commit_inputs
> 
> This commit changes the commit_inputs_store() callback to use damon_call()
> to synchronously commit parameters in the kdamond thread's safe context.
> This ensures validation errors are returned immediately to userspace.
> 
> Link: https://lore.kernel.org/20260318153731.97470-1-aethernet65535@gmail.com
> 
> > diff --git a/mm/damon/lru_sort.c b/mm/damon/lru_sort.c
> > index 554559d72976..641af42cc2d1 100644
> > --- a/mm/damon/lru_sort.c
> > +++ b/mm/damon/lru_sort.c
> 
> [ ... ]
> 
> > @@ -349,18 +348,51 @@ static int damon_lru_sort_apply_parameters(void)
> >  	return err;
> >  }
> >  
> > -static int damon_lru_sort_handle_commit_inputs(void)
> > +static int damon_lru_sort_commit_inputs_fn(void *arg)
> >  {
> > +	return damon_lru_sort_apply_parameters();
> > +}
> > +
> > +static int damon_lru_sort_commit_inputs_store(const char *val,
> > +					      const struct kernel_param *kp)
> > +{
> > +	bool commit_inputs_request;
> >  	int err;
> > +	struct damon_call_control control = {
> > +		.fn = damon_lru_sort_commit_inputs_fn,
> > +	};
> >  
> > -	if (!commit_inputs)
> > +	if (!val) {
> > +		commit_inputs_request = true;
> > +	} else {
> > +		err = kstrtobool(val, &commit_inputs_request);
> > +		if (err)
> > +			return err;
> > +	}
> >  
> > +	if (!commit_inputs_request)
> >  		return 0;
> >  
> > -	err = damon_lru_sort_apply_parameters();
> > -	commit_inputs = false;
> > -	return err;
> > +	/*
> > +	 * Skip damon_call() if ctx is not initialized to avoid
> > +	 * NULL pointer dereference.
> > +	 */
> > +	if (!ctx)
> > +		return -EINVAL;
> > +
> > +	err = damon_call(ctx, &control);
> 
> If the module has not yet been enabled (e.g., enabled=N) and the kdamond
> thread is not running, does this call to damon_call() block indefinitely?
> 
> Since ctx is allocated during initialization, the ctx pointer is not NULL.
> damon_call() then queues the control request and calls wait_for_completion().
> 
> Without the background thread running to process the queue and signal
> completion, it seems the sysfs writer task is placed into an unkillable
> D-state forever.

No.  ctx is initialized to NULL because it is static.  Once it is set,
kdamond_fn() is started.  If user stops kdamond by writing N to enabled,
ctx->call_controls_obsolete is set.  If user further writes Y to commit_inputs
for invoking damon_call(), it will return -ECANCELED due to
ctx->call_controls_obsolete.

> 
> The damon_call() documentation indicates it should only be called after
> damon_start() has succeeded, otherwise it could fall into an indefinite wait.

Yes, and that's excluded here since the module is not calling damon_call() for
NULL ctx.

> 
> > +
> > +	return err ? err : control.return_code;
> >  }
> 
> [ ... ]
> 
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index 86da14778658..4fc4a54b5e54 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> 
> [ ... ]
> 
> > @@ -255,18 +254,51 @@ static int damon_reclaim_apply_parameters(void)
> >  	return err;
> >  }
> >  
> > -static int damon_reclaim_handle_commit_inputs(void)
> > +static int damon_reclaim_commit_inputs_fn(void *arg)
> >  {
> > +	return damon_reclaim_apply_parameters();
> > +}
> > +
> > +static int damon_reclaim_commit_inputs_store(const char *val,
> > +					     const struct kernel_param *kp)
> > +{
> > +	bool commit_inputs_request;
> >  	int err;
> > +	struct damon_call_control control = {
> > +		.fn = damon_reclaim_commit_inputs_fn,
> > +	};
> >  
> > -	if (!commit_inputs)
> > +	if (!val) {
> > +		commit_inputs_request = true;
> > +	} else {
> > +		err = kstrtobool(val, &commit_inputs_request);
> > +		if (err)
> > +			return err;
> > +	}
> > +
> > +	if (!commit_inputs_request)
> >  		return 0;
> >  
> > -	err = damon_reclaim_apply_parameters();
> > -	commit_inputs = false;
> > -	return err;
> > +	/*
> > +	 * Skip damon_call() if ctx is not initialized to avoid
> > +	 * NULL pointer dereference.
> > +	 */
> > +	if (!ctx)
> > +		return -EINVAL;
> > +
> > +	err = damon_call(ctx, &control);
> 
> Could this exhibit the same hang as in damon_lru_sort.c? If the worker
> thread has not been started, does writing to commit_inputs block forever?

Same to the above reply, no.

> 
> > +
> > +	return err ? err : control.return_code;
> >  }
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260426231619.107231-1-sj@kernel.org?part=3

Sent using hkml (https://github.com/sjp38/hackermail)

  reply	other threads:[~2026-04-27 14:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-26 23:16 [PATCH v2 0/4] mm/damon: repost non-hotfix reviewed patches in damon/next tree SeongJae Park
2026-04-26 23:16 ` [PATCH v2 1/4] mm/damon/ops-common: optimize damon_hot_score() using ilog2() SeongJae Park
2026-04-26 23:28   ` sashiko-bot
2026-04-27 14:18     ` SeongJae Park
2026-04-27 15:09   ` SeongJae Park
2026-04-26 23:16 ` [PATCH v2 2/4] Docs/admin-guide/mm/damon: fix 'parametrs' typo SeongJae Park
2026-04-27 23:39   ` SeongJae Park
2026-04-28  7:38     ` Vlastimil Babka (SUSE)
2026-04-28 14:21       ` SeongJae Park
2026-04-26 23:16 ` [PATCH v2 3/4] mm/damon: add synchronous commit for commit_inputs SeongJae Park
2026-04-27  0:00   ` sashiko-bot
2026-04-27 14:30     ` SeongJae Park [this message]
2026-04-26 23:16 ` [PATCH v2 4/4] mm/damon: support MADV_COLLAPSE via DAMOS_COLLAPSE scheme action SeongJae Park
2026-04-27 23:41   ` 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=20260427143052.111666-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.