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: [RFC PATCH v2.2 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type
Date: Mon, 27 Jul 2026 21:52:21 -0700	[thread overview]
Message-ID: <20260728045222.189550-1-sj@kernel.org> (raw)
In-Reply-To: <20260728043259.ACFA71F000E9@smtp.kernel.org>

On Tue, 28 Jul 2026 04:32:59 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] DAMON_FILTER_TYPE_PGIDLE_UNSET blindly matches almost all pages when probe weights are used, rendering the filter ineffective.
> - [High] The newly added DAMON_FILTER_TYPE_PGIDLE_UNSET is not exposed in the sysfs interface, making it impossible for users to configure.
> --
> 
> --- Patch [2]: [RFC PATCH v2.2 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type ---
> commit 98c0d4f6b2dcc4c706f1af62a258dd827b89bc7e
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/paddr: support PGIDLE_UNSET probe filter type
>     
> Implement support of DAMON_FILTER_TYPE_PGIDLE_UNSET in the physical
> address space DAMON operations set. It reuses damon_folio_young(),
> which was being used for access monitoring.
> 
> > diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> > index 5a6a78054784a..199de1463fa06 100644
> > --- a/mm/damon/paddr.c
> > +++ b/mm/damon/paddr.c
> > @@ -132,6 +132,12 @@ static bool damon_pa_filter_match(struct damon_filter *filter,
> >  			matched = filter->memcg_id == mem_cgroup_id(memcg);
> >  		rcu_read_unlock();
> >  		break;
> > +	case DAMON_FILTER_TYPE_PGIDLE_UNSET:
> 
> [Severity: High]
> Is this new filter type missing from the sysfs interface mapping?
> 
> Looking at damon_sysfs_filter_type_names[] in mm/damon/sysfs.c, there is
> no entry for DAMON_FILTER_TYPE_PGIDLE_UNSET:
> 
> mm/damon/sysfs.c:damon_sysfs_filter_type_names[] = {
>         {
>                 .type = DAMON_FILTER_TYPE_ANON,
>                 .name = "anon",
>         },
>         {
>                 .type = DAMON_FILTER_TYPE_MEMCG,
>                 .name = "memcg",
>         },
> };
> 
> Without an entry here, will users attempting to configure this new filter via
> sysfs receive -EINVAL, making the filter unconfigurable?

A later patch of this series does that.

> 
> > +		if (!folio)
> > +			matched = false;
> > +		else
> > +			matched = damon_folio_young(folio);
> 
> [Severity: High]
> Will this blindly match almost all folios when probe weights are used?
> 
> In kdamond_fn(), if damon_has_probe_weights(ctx) is true, it skips
> ctx->ops.prepare_access_checks():
> 
> mm/damon/core.c:kdamond_fn() {
>         ...
>         bool access_check_disabled = damon_has_probe_weights(ctx);
>         ...
>         if (!access_check_disabled && ctx->ops.prepare_access_checks)
>                 ctx->ops.prepare_access_checks(ctx);
>         ...
> }
> 
> For physical addresses, this skips damon_pa_mkold() which normally sets the
> PG_idle flag on folios.
> 
> When the filter uses damon_folio_young() here to evaluate access,
> damon_folio_young_one() checks !folio_test_idle(folio).
> 
> Since the idle flag was never set, will this evaluate to true for all
> folios, causing the PGIDLE_UNSET filter to unconditionally match?

Yes, and it is intentional.

Later patches of this series add a way to automatically do such idle flag
setup.

> 
> > +		break;
> >  	default:
> >  		break;
> >  	}
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260728041242.187380-1-sj@kernel.org?part=2


Thanks,
SJ

  reply	other threads:[~2026-07-28  4:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-28  4:12 [RFC PATCH v2.2 00/17] mm/damon: introduce data access-as-a-data attribute SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 01/17] mm/damon/core: introduce DAMON_FILTER_TYPE_PGIDLE_UNSET SJ Park
2026-07-28  4:23   ` sashiko-bot
2026-07-28  4:49     ` SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type SJ Park
2026-07-28  4:32   ` sashiko-bot
2026-07-28  4:52     ` SJ Park [this message]
2026-07-28  4:12 ` [RFC PATCH v2.2 03/17] mm/damon/sysfs: support pgidle_unset " SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 04/17] Docs/mm/damon/design: document " SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 05/17] mm/damon/core: introduce damon_prep struct SJ Park
2026-07-28  4:25   ` sashiko-bot
2026-07-28  4:54     ` SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 06/17] mm/damon/core: commit preps SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 07/17] mm/damon/core: introduce damon_operations->prep_probes() SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 08/17] mm/damon/paddr: support damon_prep SJ Park
2026-07-28  4:24   ` sashiko-bot
2026-07-28  4:56     ` SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 09/17] mm/damon/sysfs: implement preps directory SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 10/17] mm/damon/sysfs: implement preps/nr_preps file SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 11/17] mm/damon/sysfs: create directories for nr_preps writes SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 12/17] mm/damon/sysfs: implement prep_action file SJ Park
2026-07-28  4:23   ` sashiko-bot
2026-07-28  4:58     ` SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 13/17] mm/damon/sysfs: pass preps to DAMON core SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 14/17] selftests/damon/sysfs.sh: test probe prep sysfs files SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 15/17] Docs/mm/damon/design: document probe preps SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 16/17] Docs/admin-guide/mm/damon/usage: document probe preps sysfs files SJ Park
2026-07-28  4:12 ` [RFC PATCH v2.2 17/17] Docs/ABI/damon: document probe prep " 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=20260728045222.189550-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.