From: SJ Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SJ Park <sj@kernel.org>, damon@lists.linux.dev
Subject: Re: [PATCH 6.12.y v3 2/2] mm/damon/core: fix unconditionally skip last region
Date: Fri, 9 Oct 2026 06:40:07 -0700 [thread overview]
Message-ID: <20261009134008.7127-1-sj@kernel.org> (raw)
In-Reply-To: <sashiko-outbox-165593@kernel.org>
On Fri, 09 Oct 2026 13:06:32 +0000 sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] mm/damon: dangling charge_target_from pointer permanently freezes schemes
> --
>
> commit a9baf64370898b2dec04fa2f17e4061166d6d27a
> Author: Liew Rui Yan <aethernet65535@gmail.com>
>
> mm/damon/core: fix unconditionally skip last region
>
> This commit modifies damos_skip_charged_region() to clear the quota's
> charge_target_from pointer only when the last region of a target is
> reached, rather than clearing it unconditionally during previous charge
> checks.
>
> Link: https://lore.kernel.org/20260908134739.96919-1-sj@kernel.org
>
> > diff --git a/mm/damon/core.c b/mm/damon/core.c
> > --- a/mm/damon/core.c
> > +++ b/mm/damon/core.c
> > @@ -1323,36 +1323,39 @@ static bool damos_skip_charged_region(struct damon_target *t,
> > struct damon_region *r, struct damos *s)
> > {
> > struct damos_quota *quota = &s->quota;
> > unsigned long sz_to_skip;
> > + bool skip = false;
> >
> > /* Skip previously charged regions */
> > if (quota->charge_target_from) {
> > if (t != quota->charge_target_from)
> > return true;
>
> [ ... ]
>
> > + }
> > +out:
> > + if (r = damon_last_region(t)) {
> > quota->charge_target_from = NULL;
> > quota->charge_addr_from = 0;
> > }
>
> [Severity: High]
> If the target tracked by quota->charge_target_from is dynamically
> destroyed via sysfs, or if it loses all of its regions, will this
> clearing logic ever be reached?
Good finding. But this is pre-existing issue that also exist in the mainline
tree. So not a blocker of this patch in my opinion. I will separately working
on this.
>
> If the saved target is removed or has zero regions, the region loop will
> be empty, meaning r = damon_last_region(t) is never evaluated for
> that target.
>
> Since charge_target_from is never cleared in these scenarios, wouldn't
> this cause the condition earlier in this function:
>
> if (t != quota->charge_target_from)
> return true;
>
> to remain true indefinitely for all other valid targets, permanently
> freezing the scheme? Additionally, if the target is freed, does this
> leave a dangling pointer comparison for future checks?
>
> > - return false;
> > + return skip;
> > }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261009123651.6585-1-sj@kernel.org?part=2
>
Thanks,
SJ
next prev parent reply other threads:[~2026-10-09 13:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2026092948-agency-overhand-3fd1@gregkh>
2026-09-30 9:28 ` [PATCH 6.12.y] mm/damon/core: fix unconditionally skip last region SJ Park
2026-09-30 9:53 ` sashiko-bot
2026-09-30 10:01 ` SJ Park
2026-09-30 10:03 ` SJ Park
2026-09-30 10:14 ` [PATCH 6.12.y v2] " SJ Park
2026-09-30 10:26 ` sashiko-bot
2026-09-30 10:34 ` SJ Park
2026-10-02 14:19 ` Sasha Levin
2026-10-09 12:36 ` [PATCH 6.12.y v3 0/2] mm/damon/core: fix last region handling of damos_skip_charged_regions() SJ Park
2026-10-09 12:36 ` [PATCH 6.12.y v3 1/2] mm/damon/core: do non-safe region walk on kdamond_apply_schemes() SJ Park
2026-10-09 12:55 ` sashiko-bot
2026-10-09 13:42 ` SJ Park
2026-10-09 12:36 ` [PATCH 6.12.y v3 2/2] mm/damon/core: fix unconditionally skip last region SJ Park
2026-10-09 13:06 ` sashiko-bot
2026-10-09 13:40 ` SJ Park [this message]
2026-10-11 16:48 ` [PATCH 6.12.y v3 0/2] mm/damon/core: fix last region handling of damos_skip_charged_regions() Sasha Levin
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=20261009134008.7127-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.