All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.