All of lore.kernel.org
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx has not started
Date: Mon,  3 Aug 2026 07:19:46 -0700	[thread overview]
Message-ID: <20260803141947.17523-1-sj@kernel.org> (raw)
In-Reply-To: <20260803140642.0DCE51F00A3A@smtp.kernel.org>

On Mon, 03 Aug 2026 14:06:41 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [Medium] The patch fixes an indefinite hang in `mm/damon/reclaim.c` when `commit_inputs` is written before the context is started, but completely misses the identical vulnerability in `mm/damon/lru_sort.c`.
> --
> 
> --- Patch [1]: [PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx has not started ---
> commit d00b612017f41a8bee83736cc54b16dba8d079ff
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/reclaim: skip damon_call() if ctx has not started
> 
> DAMON_RECLAIM calls damon_call() for commit_inputs parameter user input
> if the DAMON context is initialized. The context could be initialized,
> but not yet successfully started. In the case, damon_call() could
> indefinitely hang. Fix the problem by memorizing if the DAMON context
> has ever successfully started, and skip damon_call() if it has not.
> 
> > diff --git a/mm/damon/reclaim.c b/mm/damon/reclaim.c
> > index 09e941d75f67d..45d5557cc575a 100644
> > --- a/mm/damon/reclaim.c
> > +++ b/mm/damon/reclaim.c
> [ ... ]
> > @@ -291,11 +293,8 @@ static int damon_reclaim_commit_inputs_store(const char *val,
> >  	if (!commit_inputs_request)
> >  		return 0;
> >  
> > -	/*
> > -	 * Skip damon_call() if ctx is not initialized to avoid
> > -	 * NULL pointer dereference.
> > -	 */
> > -	if (!ctx)
> > +	/* Skip damon_call() if ctx has not successfully started. */
> > +	if (!damon_reclaim_damon_has_started)
> >  		return -EINVAL;
> >  
> >  	err = damon_call(ctx, &control);
> 
> [Severity: Medium]
> This is a pre-existing issue and was not introduced by the patch under review,
> but does mm/damon/lru_sort.c also need this same fix?
> 
> Looking at damon_lru_sort_commit_inputs_store() in mm/damon/lru_sort.c, it
> retains the identical vulnerable logic that was patched here in reclaim.c:
> 
> mm/damon/lru_sort.c:damon_lru_sort_commit_inputs_store() {
>     ...
>         /*
>          * Skip damon_call() if ctx is not initialized to avoid
>          * NULL pointer dereference.
>          */
>         if (!ctx)
>                 return -EINVAL;
> 
>         err = damon_call(ctx, &control);
>     ...
> }
> 
> If a user writes 'Y' to /sys/module/damon_lru_sort/parameters/commit_inputs
> before the damon_lru_sort module has been turned on for the first time,
> damon_call() is invoked before the kdamond thread has been created.
> Will this cause the caller to hang indefinitely in wait_for_completion()
> just like the reclaim.c version did?
> 
> Should a similar damon_lru_sort_damon_has_started flag be tracked in
> damon_lru_sort_turn() to fix this in lru_sort.c as well?

The next patch of this series fixes the bug.

> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260803134646.16640-1-sj@kernel.org?part=1


Thanks,
SJ

  reply	other threads:[~2026-08-03 14:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-03 13:46 [PATCH 0/2] mm/damon/{reclaim,lru_sort}: fix commit_inputs infinite hang SJ Park
2026-08-03 13:46 ` [PATCH 1/2] mm/damon/reclaim: skip damon_call() if ctx has not started SJ Park
2026-08-03 14:06   ` sashiko-bot
2026-08-03 14:19     ` SJ Park [this message]
2026-08-03 13:46 ` [PATCH 2/2] mm/damon/lru_sort: " 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=20260803141947.17523-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.