All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "SJ Park" <sj@kernel.org>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 08/17] mm/damon/paddr: support damon_prep
Date: Tue, 01 Sep 2026 04:47:02 +0000	[thread overview]
Message-ID: <20260901044702.A19E71F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901043417.2165-9-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `damon_pa_prep_probes` applies probe preparation actions without checking probe filters, causing unintended page state modifications and redundant folio lookups.
--

commit 05f1236264960a0054ba7741a1b9b7ae78666ee1
Author: SJ Park <sj@kernel.org>

mm/damon/paddr: support damon_prep

This commit implements the prep_probes() callback for damon_operations. It
adds support for the DAMON_PREP_SET_PGIDLE preparation action by unsetting
page table accessed bits and setting the PG_idle flag via damon_pa_mkold().

> diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
> index 5b307dcbb2a50..8fb71183b76c0 100644
> --- a/mm/damon/paddr.c
> +++ b/mm/damon/paddr.c

[ ... ]

> @@ -105,6 +105,40 @@ static unsigned int damon_pa_check_accesses(struct damon_ctx *ctx)
>  	return max_nr_accesses;
>  }
>  
> +static void damon_pa_prep_probes_region(struct damon_region *r,
> +		struct damon_probe *probe, struct damon_ctx *ctx)
> +{
> +	struct damon_prep *p;
> +
> +	damon_for_each_prep(p, probe) {
> +		switch (p->action) {
> +		case DAMON_PREP_SET_PGIDLE:
> +			damon_pa_mkold(damon_pa_phys_addr(r->sampling_addr,
> +						ctx->addr_unit));

[Severity: Medium]
Will this unconditionally mutate the page state for every prep action,
regardless of whether the page passes the probe's filters?

Because damon_pa_prep_probes_region() doesn't check the filters, it appears
it will clear the accessed bit and set PG_idle on pages that are explicitly
excluded (e.g., when a probe only targets a specific memcg).

Could this disrupt legitimate LRU tracking and reclaim for processes not
targeted by the probe?

> +			break;
> +		default:
> +			break;
> +		}
> +	}
> +}
> +
> +static void damon_pa_prep_probes(struct damon_ctx *ctx, bool set_samples)
> +{
> +	struct damon_target *t;
> +	struct damon_region *r;
> +	struct damon_probe *p;
> +
> +	damon_for_each_target(t, ctx) {
> +		damon_for_each_region(r, t) {
> +			if (set_samples)
> +				r->sampling_addr = damon_rand(ctx, r->ar.start,
> +						r->ar.end);
> +			damon_for_each_probe(p, ctx)
> +				damon_pa_prep_probes_region(r, p, ctx);

[Severity: Medium]
Since damon_pa_prep_probes_region() is called in a nested loop for each probe,
could this cause redundant work?

If multiple probes use DAMON_PREP_SET_PGIDLE, this will redundantly invoke
damon_pa_mkold() multiple times on the exact same physical address, leading to
unnecessary folio lookups and reference cycles per region.

> +		}
> +	}
> +}

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

  reply	other threads:[~2026-09-01  4:47 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  4:33 [PATCH 00/17] mm/damon: introduce data access-as-a-data attribute SJ Park
2026-09-01  4:33 ` [PATCH 01/17] mm/damon/core: introduce DAMON_FILTER_TYPE_PGIDLE_UNSET SJ Park
2026-09-01  4:41   ` sashiko-bot
2026-09-01  4:33 ` [PATCH 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type SJ Park
2026-09-01  4:41   ` sashiko-bot
2026-09-01  4:33 ` [PATCH 03/17] mm/damon/sysfs: support pgidle_unset " SJ Park
2026-09-01  4:42   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 04/17] Docs/mm/damon/design: document " SJ Park
2026-09-01  4:35   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 05/17] mm/damon/core: introduce damon_prep struct SJ Park
2026-09-01  4:46   ` sashiko-bot
2026-09-01  5:01     ` SJ Park
2026-09-01  4:34 ` [PATCH 06/17] mm/damon/core: commit preps SJ Park
2026-09-01  4:43   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 07/17] mm/damon/core: introduce damon_operations->prep_probes() SJ Park
2026-09-01  4:40   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 08/17] mm/damon/paddr: support damon_prep SJ Park
2026-09-01  4:47   ` sashiko-bot [this message]
2026-09-01  5:05     ` SJ Park
2026-09-01  4:34 ` [PATCH 09/17] mm/damon/sysfs: implement preps directory SJ Park
2026-09-01  4:40   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 10/17] mm/damon/sysfs: implement preps/nr_preps file SJ Park
2026-09-01  4:42   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 11/17] mm/damon/sysfs: create directories for nr_preps writes SJ Park
2026-09-01  4:40   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 12/17] mm/damon/sysfs: implement prep_action file SJ Park
2026-09-01  4:40   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 13/17] mm/damon/sysfs: pass preps to DAMON core SJ Park
2026-09-01  4:53   ` sashiko-bot
2026-09-01  5:24     ` SJ Park
2026-09-01  4:34 ` [PATCH 14/17] selftests/damon/sysfs.sh: test probe prep sysfs files SJ Park
2026-09-01  4:36   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 15/17] Docs/mm/damon/design: document probe preps SJ Park
2026-09-01  4:35   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 16/17] Docs/admin-guide/mm/damon/usage: document probe preps sysfs files SJ Park
2026-09-01  4:38   ` sashiko-bot
2026-09-01  4:34 ` [PATCH 17/17] Docs/ABI/damon: document probe prep " SJ Park
2026-09-01  4:36   ` sashiko-bot
2026-09-01  5:26 ` [PATCH 00/17] mm/damon: introduce data access-as-a-data attribute 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=20260901044702.A19E71F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sj@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.