DAMON development mailing list
 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 v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT
Date: Sun, 02 Aug 2026 16:36:30 +0000	[thread overview]
Message-ID: <20260802163631.33F561F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260802162631.90304-6-sj@kernel.org>

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

Pre-existing issues:
- [High] Unsafe blind PTE batching skips intermediate mappings and misses per-PTE Accessed/Young bits for large folios.
--

--- Patch [5]: [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT ---
commit d6ffeea9e85e0fc3aa2c2575b8113904f9da4123
Author: SJ Park <sj@kernel.org>

mm/damon/vaddr: respect folio end for DAMOS_STAT

This commit fixes an issue in DAMOS_STAT page-level monitoring where the
address advancement could incorrectly skip folios if a region starts in the
middle of a large folio. It ensures the address is advanced exactly to the
start of the next folio by calculating the correct page index.

[1] https://lore.kernel.org/20260514015053.149396-1-sj@kernel.org

> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 0648400b2d65b..4b0b5edf67952 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
[ ... ]
> @@ -844,7 +846,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned long addr,
>  
>  		if (!damos_va_filter_out(s, folio, vma, addr, pte, NULL))
>  			*sz_filter_passed += folio_size(folio);
> -		nr = folio_nr_pages(folio);
> +		page_idx = folio_page_idx(folio, pte_page(ptent));
> +		nr = folio_nr_pages(folio) - page_idx;

[Severity: High]
This is a pre-existing issue, but does this blind PTE batching skip
intermediate mappings and miss per-PTE Accessed/Young bits for large folios?

When damos_va_filter_out() tests the young filter, it only checks the
accessed bit of the first pte. By unconditionally advancing pte += nr without
aggregating the accessed bits of the remaining subpages, could this miss
hardware accesses on PTE-mapped large folios (like mTHP) and cause DAMON to
falsely classify actively used memory as cold?

Additionally, if userspace partially unmaps or remaps portions of this large
folio (for example, via MADV_DONTNEED or mmap), the page table might contain
different folios or empty entries in the skipped range. By blindly advancing
the PTE walker based purely on the first folio's size, does this ignore those
mixed mappings and fail to monitor the substituted folios?

>  		s->last_applied = folio;
>  	}
>  	pte_unmap_unlock(start_pte, ptl);

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

  reply	other threads:[~2026-08-02 16:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-02 16:26 [RFC PATCH v1.1 0/9] mm/damon: fix DAMOS bugs in core, paddr and vaddr SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 1/9] mm/damon/core: skip applying scheme if region split for quota fails SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 2/9] mm/damon/core: initialize damos_quota_goal->last_psi_total SJ Park
2026-08-02 16:43   ` sashiko-bot
2026-08-02 17:41     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT SJ Park
2026-08-02 16:34   ` sashiko-bot
2026-08-02 17:43     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 4/9] mm/damon/paddr: respect folio end for DAMOS actions except STAT SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT SJ Park
2026-08-02 16:36   ` sashiko-bot [this message]
2026-08-02 17:45     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 6/9] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() SJ Park
2026-08-02 16:35   ` sashiko-bot
2026-08-02 17:49     ` SJ Park
2026-08-02 17:59       ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 8/9] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() SJ Park
2026-08-02 16:38   ` sashiko-bot
2026-08-02 17:51     ` SJ Park
2026-08-02 16:26 ` [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() SJ Park
2026-08-02 16:51   ` sashiko-bot
2026-08-02 17:51     ` 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=20260802163631.33F561F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox