From: sashiko-bot@kernel.org
To: "Krishna Iyer" <kiyer@crusoe.ai>
Cc: damon@lists.linux.dev
Subject: Re: [PATCH 1/6] mm/damon: move damon_hugetlb_mkold() from vaddr to ops-common
Date: Sun, 30 Aug 2026 05:26:29 +0000 [thread overview]
Message-ID: <20260830052629.CC44C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260830051407.50008-2-kiyer@crusoe.ai>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Non-atomic update of HugeTLB PTE in damon_hugetlb_mkold() overwrites hardware-set dirty bits and triggers unintended BBM sequences.
--
commit a960b7ee57eac1d4fccc44af4918b4b8331a38a3
Author: Krishna Iyer <kiyer@crusoe.ai>
mm/damon: move damon_hugetlb_mkold() from vaddr to ops-common
damon_hugetlb_mkold() clears the accessed bit of a hugetlb-mapping huge
PTE and propagates the aging to secondary MMUs via
mmu_notifier_clear_young(), spanning the whole huge page size. It
currently lives in vaddr.c, and is thus usable only by the virtual
address space monitoring operations set.
> diff --git a/mm/damon/ops-common.c b/mm/damon/ops-common.c
> index fbda70d8ea4d0..f5fe92b825bbc 100644
> --- a/mm/damon/ops-common.c
> +++ b/mm/damon/ops-common.c
[ ... ]
> @@ -98,6 +99,35 @@ void damon_pmdp_mkold(pmd_t *pmd, struct vm_area_struct *vma, unsigned long addr
> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
> }
>
> +#ifdef CONFIG_HUGETLB_PAGE
> +void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm,
> + struct vm_area_struct *vma, unsigned long addr)
> +{
> + bool referenced = false;
> + pte_t entry = huge_ptep_get(mm, addr, pte);
> + struct folio *folio = pfn_folio(pte_pfn(entry));
> + unsigned long psize = huge_page_size(hstate_vma(vma));
> +
> + folio_get(folio);
> +
> + if (pte_young(entry)) {
> + referenced = true;
> + entry = pte_mkold(entry);
> + set_huge_pte_at(mm, addr, pte, entry, psize);
[Severity: Critical]
This is a pre-existing issue, but does this non-atomic update of the hugetlb
PTE overwrite hardware-set dirty bits?
The hardware MMU can set the dirty bit (on x86, or arm64 with hardware managed
dirty bits) between the huge_ptep_get() read and this set_huge_pte_at()
write. This non-atomic read-modify-write drops the hardware dirty bit, leading
to data loss upon reclaim or sync.
Additionally, on arm64, using set_huge_pte_at() on an already valid contiguous
PTE triggers an unintended break-before-make sequence with a broadcast TLB
flush via clear_flush(), which causes severe performance regressions.
> + }
> +
> + if (mmu_notifier_clear_young(mm, addr,
> + addr + huge_page_size(hstate_vma(vma))))
> + referenced = true;
> +
> + if (referenced)
> + folio_set_young(folio);
> +
> + folio_set_idle(folio);
> + folio_put(folio);
> +}
> +#endif /* CONFIG_HUGETLB_PAGE */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260830051407.50008-1-kiyer@crusoe.ai?part=1
next prev parent reply other threads:[~2026-08-30 5:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-30 5:14 [PATCH 0/6] mm/damon: support access monitoring of hugetlb-backed memory Krishna Iyer
2026-08-30 5:14 ` [PATCH 1/6] mm/damon: move damon_hugetlb_mkold() from vaddr to ops-common Krishna Iyer
2026-08-30 5:26 ` sashiko-bot [this message]
2026-08-30 16:05 ` SJ Park
2026-08-30 16:33 ` SJ Park
2026-08-30 5:14 ` [PATCH 2/6] mm/damon/ops-common: handle hugetlb folios in folio mkold/young rmap walkers Krishna Iyer
2026-08-30 5:28 ` sashiko-bot
2026-08-30 16:13 ` SJ Park
2026-08-30 18:10 ` SJ Park
2026-08-30 16:48 ` SJ Park
2026-08-30 5:14 ` [PATCH 3/6] mm/damon/paddr: support hugetlb folios in access monitoring Krishna Iyer
2026-08-30 5:29 ` sashiko-bot
2026-08-30 16:15 ` SJ Park
2026-08-30 17:12 ` SJ Park
2026-08-30 5:14 ` [PATCH 4/6] mm/damon: support flush-assisted access bit clearing for monitoring Krishna Iyer
2026-08-30 5:23 ` sashiko-bot
2026-08-30 5:14 ` [PATCH 5/6] mm/damon/sysfs: support aging_flush Krishna Iyer
2026-08-30 5:22 ` sashiko-bot
2026-08-30 5:14 ` [PATCH 6/6] mm/damon/stat: " Krishna Iyer
2026-08-30 5:18 ` sashiko-bot
2026-08-30 18:04 ` [PATCH 0/6] mm/damon: support access monitoring of hugetlb-backed memory 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=20260830052629.CC44C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=damon@lists.linux.dev \
--cc=kiyer@crusoe.ai \
--cc=sashiko-reviews@lists.linux.dev \
/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.