From: Marc Zyngier <maz@kernel.org>
To: Wei-Lin Chang <weilin.chang@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Oliver Upton <oupton@kernel.org>,
Fuad Tabba <tabba@google.com>, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Dev Jain <dev.jain@arm.com>, Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Matt Fleming <matt@codeblueprint.co.uk>,
Vincent Donnefort <vdonnefort@google.com>,
Sebastian Ene <sebastianene@google.com>
Subject: Re: [PATCH v3 1/2] arm64: ptdump: Make note_page_flush() range aware
Date: Sat, 15 Aug 2026 12:28:23 +0100 [thread overview]
Message-ID: <86v79bzkq0.wl-maz@kernel.org> (raw)
In-Reply-To: <20260814222458.584906-2-weilin.chang@arm.com>
On Fri, 14 Aug 2026 23:24:57 +0100,
Wei-Lin Chang <weilin.chang@arm.com> wrote:
>
> note_page_flush() calls note_page() with addr == 0 and level == -1 to
> dump the last row of a ptdump. addr == 0 (1 << 64 wrapped around)
> renders a huge region with enormous size for address spaces with
> IA bits < 64. For example the stage-2 page tables and the EFI runtime
> page table.
>
> More importantly, the last region of the address space and everything
> after the address space up to 1 << 64 are merged into one row of
> output. If the last region within the address space is valid, it will
> appear to remain valid up to 1 << 64 with the same attributes.
>
> Currently only the EFI runtime ptdump is affected by this, but KVM will
> soon fix its stage-2 ptdump by using note_page_flush(). Here is an
> example of an EFI runtime ptdump (last row):
>
> 0x0000008000000000-0x0000000000000000 17179868672G PGD
>
> With this patch:
>
> 0x0000008000000000-0x0001000000000000 261632G PGD
>
> To fix this, cache the end address of a ptdump in ptdump_pg_state so
> note_page_flush() can call the final note_page() with the correct end
> address.
>
> Fixes: 9d80448ac92b ("efi/arm64: Add debugfs node to dump UEFI runtime page tables")
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/include/asm/ptdump.h | 2 ++
> arch/arm64/mm/ptdump.c | 14 +++++++++++++-
> 2 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/ptdump.h b/arch/arm64/include/asm/ptdump.h
> index 5b374a6ab34a..1b743de7d89e 100644
> --- a/arch/arm64/include/asm/ptdump.h
> +++ b/arch/arm64/include/asm/ptdump.h
> @@ -52,6 +52,8 @@ struct ptdump_pg_state {
> const struct addr_marker *marker;
> const struct mm_struct *mm;
> unsigned long start_address;
> + /* exclusive end, ULONG_MAX represents an end at 1 << 64 */
> + unsigned long end_address;
> int level;
> ptval_t current_prot;
> bool check_wx;
> diff --git a/arch/arm64/mm/ptdump.c b/arch/arm64/mm/ptdump.c
> index 1c20144700d7..eab400e744d9 100644
> --- a/arch/arm64/mm/ptdump.c
> +++ b/arch/arm64/mm/ptdump.c
> @@ -278,9 +278,19 @@ void note_page_pgd(struct ptdump_state *pt_st, unsigned long addr, pgd_t pgd)
>
> void note_page_flush(struct ptdump_state *pt_st)
> {
> + struct ptdump_pg_state *st = container_of(pt_st, struct ptdump_pg_state, ptdump);
> + unsigned long end = st->end_address;
> pte_t pte_zero = {0};
>
> - note_page(pt_st, 0, -1, pte_val(pte_zero));
> + /*
> + * Address spaces that end at 1 << 64 have end_address == ULONG_MAX,
> + * but note_page() expects the exclusive end. In this case adjust end
> + * to the wraparound value 0.
> + */
> + if (end == ULONG_MAX)
> + end = 0;
> +
> + note_page(pt_st, end, -1, pte_val(pte_zero));
> }
>
> static void arm64_ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm)
> @@ -303,6 +313,7 @@ void ptdump_walk(struct seq_file *s, struct ptdump_info *info)
> .marker = info->markers,
> .mm = info->mm,
> .pg_level = &kernel_pg_levels[0],
> + .end_address = end,
> .level = -1,
> .ptdump = {
> .note_page_pte = note_page_pte,
> @@ -344,6 +355,7 @@ bool ptdump_check_wx(void)
> { -1, NULL},
> },
> .pg_level = &kernel_pg_levels[0],
> + .end_address = ~0UL,
nit: shouldn't this be ULONG_MAX instead? Yes, this is the same thing,
but it doesn't hurt to match the documentation.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-08-15 11:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 22:24 [PATCH v3 0/2] arm64: ptdump flush fixes Wei-Lin Chang
2026-08-14 22:24 ` [PATCH v3 1/2] arm64: ptdump: Make note_page_flush() range aware Wei-Lin Chang
2026-08-15 11:28 ` Marc Zyngier [this message]
2026-08-15 23:16 ` Wei-Lin Chang
2026-08-14 22:24 ` [PATCH v3 2/2] KVM: arm64: ptdump: Flush the last region Wei-Lin Chang
2026-08-23 10:13 ` [PATCH v3 0/2] arm64: ptdump flush fixes Marc Zyngier
2026-08-24 13:30 ` Will Deacon
2026-08-24 16:01 ` Will Deacon
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=86v79bzkq0.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=matt@codeblueprint.co.uk \
--cc=oupton@kernel.org \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sebastianene@google.com \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=weilin.chang@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.