Re: [PATCH] mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()

[SJ Park <sj@kernel.org>]

On Mon, 07 Sep 2026 17:16:13 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Modifying contiguous huge PTEs by clearing and re-setting without an intermediate TLB flush violates Break-Before-Make (BBM) rules on architectures like arm64, potentially causing fatal TLB conflict aborts.
> --
> 
> commit 1fee0c4237cb61938cdabe61cd4adf713c7ddbec
> Author: SJ Park <sj@kernel.org>
> 
> mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()
> 
> This commit attempts to prevent hardware-driven PTE updates (like dirty bits)
> from being lost during DAMON's mkold operation on hugetlb pages. It does this
> by replacing huge_ptep_get() with huge_ptep_get_and_clear() before calling
> set_huge_pte_at().
> 
> Link: https://lore.kernel.org/20260830160545.98969-1-sj@kernel.org
> Link: https://lore.kernel.org/20260906195417.103263-1-sj@kernel.org
> 
> > diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> > index f884d3f78f30a..91a0d441c1f94 100644
> > --- a/mm/damon/vaddr.c
> > +++ b/mm/damon/vaddr.c
> 
> [ ... ]
> 
> > @@ -283,22 +283,29 @@ static int damon_mkold_pmd_entry(pmd_t *pmd, unsigned long addr,
> >  }
> >  
> >  #ifdef CONFIG_HUGETLB_PAGE
> > +static bool damon_hugetlb_ptep_mkold(pte_t *pte, struct mm_struct *mm,
> > +		struct vm_area_struct *vma, unsigned long addr, pte_t *entry)
> > +{
> > +	unsigned long psize = huge_page_size(hstate_vma(vma));
> > +
> > +	if (!pte_young(*entry))
> > +		return false;
> > +	*entry = huge_ptep_get_and_clear(mm, addr, pte, psize);
> > +	*entry = pte_mkold(*entry);
> > +	set_huge_pte_at(mm, addr, pte, *entry, psize);
> 
> [Severity: High]
> Does this modification of contiguous huge PTEs violate Break-Before-Make (BBM)
> rules on architectures like arm64?
> 
> By calling huge_ptep_get_and_clear() followed by set_huge_pte_at() without an
> intermediate TLB flush, the hardware might cache conflicting contiguous TLB
> entries, which could cause fatal TLB conflict aborts. On arm64,
> huge_ptep_get_and_clear() clears the constituent PTEs but does not flush the
> TLB. When set_huge_pte_at() is subsequently called, it skips its internal BBM
> TLB flush because the PTEs were already cleared and its internal validity
> check evaluates to false.

But we are changing only accessed bit.  I think BBM is not required for this?
Please correct me if I'm wrong.

> 
> > +	return true;
> > +}
> > +
> >  static void damon_hugetlb_mkold(pte_t *pte, struct mm_struct *mm,
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20260907170358.100168-1-sj@kernel.org?part=1


Thanks,
SJ