Re: [PATCH v3 1/2] arm64: ptdump: Make note_page_flush() range aware

[Wei-Lin Chang]

On Sat, Aug 15, 2026 at 12:28:23PM +0100, Marc Zyngier wrote:
> On Fri, 14 Aug 2026 23:24:57 +0100,
> Wei-Lin Chang <weilin.chang@xxxxxxx> 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@xxxxxxx>
> > ---
> >  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.

I wrote ~0UL because the range[] initialization was using ~0UL so I did
the same for consistency. I think changing them both to ULONG_MAX is the
better approach. I'll do that if a v4 is required.

Thanks,
Wei-Lin Chang

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.