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: [RFC PATCH 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type
Date: Sat, 25 Jul 2026 21:17:05 +0000	[thread overview]
Message-ID: <20260725211706.5108E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260725210225.129944-3-sj@kernel.org>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The PGIDLE_UNSET probe filter lacks a mechanism to clear the page idle state and PTE young bits at the start of the sampling interval when used with weights, breaking access monitoring.

Pre-existing issues:
- [High] PFN advancement after page-to-folio conversion using `folio_size()` causes subsequent folios to be skipped if the iteration does not start at the folio's base address.
--

--- Patch [2]: [RFC PATCH 02/17] mm/damon/paddr: support PGIDLE_UNSET probe filter type ---
commit 97a45c1fa60aa6c710c0c0c9226adf390fa8207f
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:
> +		if (!folio)
> +			matched = false;
> +		else
> +			matched = damon_folio_young(folio);

[Severity: High]
Does this filter evaluate historical access state instead of interval-specific
accesses when used with weights?

If a DAMON probe is configured with weights, it skips the
prepare_access_checks() phase:

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);
    ...
}

Because damon_pa_mkold() is never called on this address at the beginning
of the interval, it seems damon_folio_young() will read stale access state
and perpetually match once a page is accessed.

> +		break;
>  	default:
>  		break;
>  	}

[Severity: High]
This isn't a bug introduced by this patch, but does the address advancement
in damon_pa_pageout() skip valid physical memory if the DAMON region
boundary is not aligned to a large folio boundary?

mm/damon/paddr.c:damon_pa_pageout() {
    ...
    folio = damon_get_folio(...);
    ...
    addr += folio_size(folio);
    ...
}

When damon_get_folio() returns a large folio, unconditionally adding the full
folio_size(folio) to an unaligned addr over-advances the address by
addr % folio_size(folio). This could cause the loop to skip the beginning
of the next folio.

The same unaligned address advancement also appears in damon_pa_de_activate(),
damon_pa_migrate(), and damon_pa_stat().

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

  reply	other threads:[~2026-07-25 21:17 UTC|newest]

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