All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Nathan Gao <zcgao@amazon.com>, sj@kernel.org, akpm@linux-foundation.org
Cc: damon@lists.linux.dev, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, david@kernel.org,
	ryan.roberts@arm.com
Subject: Re: [PATCH v4] mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold()
Date: Wed, 2 Sep 2026 13:27:27 +0800	[thread overview]
Message-ID: <34fda62f-a2d0-4db8-9590-c8dc834674b8@linux.alibaba.com> (raw)
In-Reply-To: <20260902031655.84721-1-zcgao@amazon.com>



On 9/2/26 11:16 AM, Nathan Gao wrote:
> __damon_va_prepare_access_check() picks a random byte address within the
> region and stores it in r->sampling_addr. damon_va_mkold() passes it into
> a page table walk, which hands it to damon_ptep_mkold() as the address of
> the page to sample:
> 
>    damon_va_mkold(mm, r->sampling_addr)
>      damon_va_walk_page_range(mm, addr, addr + 1)
>        damon_mkold_pmd_entry()
>          damon_ptep_mkold(pte, vma, addr)
>            ptep_test_and_clear_young(vma, addr, pte)
>            mmu_notifier_clear_young(mm, addr, addr + PAGE_SIZE)
> 
> For arm64, before commit 6f0e1142173a ("arm64: mm: support batch
> clearing of the young flag for large folios"), the contpte helper walked
> exactly CONT_PTES entries from the aligned-down page table pointer and
> used @addr only to pass down to each entry, so an unaligned value was
> harmless:
> 
>          ptep = contpte_align_down(ptep);
>          addr = ALIGN_DOWN(addr, CONT_PTE_SIZE);
>          for (i = 0; i < CONT_PTES; i++, ptep++, addr += PAGE_SIZE)
> 
> Now the range to walk is derived from @addr instead: end = addr +
> nr * PAGE_SIZE, rounded up to CONT_PTE_SIZE. For a sample in the last
> page of a contpte block, the sub-page offset puts end just past the
> block boundary, so the round-up lands a whole block further and the
> walk clears PTE_AF in CONT_PTES entries beyond the sampled block. For
> the last block in a page table page, those entries are past the end of
> that page, so the walk writes into the page that follows.
> 
> Triggered by the full 7.1/7.2 kernel selftest suite on arm64 (EC2
> c/m6g.4xlarge). The kernel sometimes crashes at or shortly after the
> DAMON test.
> 
> What the overrun does depends on the page that happens to follow the
> page table, so there is no single signature. If that page is read-only,
> the write faults in the sampling path itself:
> 
>    Unable to handle kernel write to read-only memory at virtual address ffff0003c5d2d000
>      FSC = 0x0f: level 3 permission fault
>      CM = 0, WnR = 1, TnD = 0, TagAccess = 0
>    CPU: 10 UID: 0 PID: 3487 Comm: kdamond.2
>    pc : contpte_test_and_clear_young_ptes+0x70/0xc0
>    lr : damon_ptep_mkold+0x1e8/0x1f8
>    Call trace:
>     contpte_test_and_clear_young_ptes+0x70/0xc0 (P)
>     damon_mkold_pmd_entry+0x150/0x170
>     walk_pmd_range+0x110/0x2b0
>     walk_pud_range+0x10c/0x208
>     walk_pgd_range+0x134/0x258
>     __walk_page_range+0x98/0x1b0
>     walk_page_range_vma_unsafe+0x90/0x148
>     walk_page_range_vma+0x28/0x40
>     damon_va_walk_page_range+0x114/0x2b8
>     damon_va_prepare_access_checks+0xec/0x1a8
>     kdamond_fn+0x534/0x770
>     kthread+0x128/0x138
>     ret_from_fork+0x10/0x20
> 
> Otherwise the page is writable, the PTE_AF clearing succeeds silently
> and the damage only surfaces later, in whatever happened to own the
> page, so the backtrace is unrelated to DAMON and differs between runs.
> 
> Pass a page-aligned address to the ptep_test_and_clear_young() call in
> damon_ptep_mkold(), which is the only place DAMON can reach
> contpte_test_and_clear_young_ptes() from. Nothing else sees the aligned
> address, and r->sampling_addr itself is left as is, so the sampling and
> region bookkeeping semantics are unchanged.
> 
> Fixes: 6f0e1142173a ("arm64: mm: support batch clearing of the young flag for large folios")
> Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
> Cc: David Hildenbrand (Arm) <david@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Nathan Gao <zcgao@amazon.com>
> ---

LGTM.
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>


      parent reply	other threads:[~2026-09-02  5:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  3:16 [PATCH v4] mm/damon/ops-common: use a page-aligned address in damon_ptep_mkold() Nathan Gao
2026-09-02  3:24 ` sashiko-bot
2026-09-02  4:06 ` SJ Park
2026-09-02  5:27 ` Baolin Wang [this message]

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=34fda62f-a2d0-4db8-9590-c8dc834674b8@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=sj@kernel.org \
    --cc=zcgao@amazon.com \
    /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.