mirror of https://lore.kernel.org/lkml/
 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: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  3:16 Nathan Gao
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®