Re: [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT

[email protected] Sun, 02 Aug 2026 16:36:30 +0000
Newsgroups dev.linux.lists.damon
Message-ID <[email protected]>
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 p=
er-PTE Accessed/Young bits for large folios.
--

--- Patch [5]: [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for D=
AMOS_STAT ---
commit d6ffeea9e85e0fc3aa2c2575b8113904f9da4123
Author: SJ Park <[email protected]>

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/[email protected]

> 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, unsign=
ed long addr,
> =20
>  		if (!damos_va_filter_out(s, folio, vma, addr, pte, NULL))
>  			*sz_filter_passed +=3D folio_size(folio);
> -		nr =3D folio_nr_pages(folio);
> +		page_idx =3D folio_page_idx(folio, pte_page(ptent));
> +		nr =3D 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 +=3D nr wit=
hout
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 tho=
se
mixed mappings and fail to monitor the substituted folios?

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

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260802162631.9030=
[email protected]?part=3D5