On Tue, 27 Jan 2026 at 11:04, Ryan Roberts <[email protected]> wrote:
>
> On 27/01/2026 09:49, Ard Biesheuvel wrote:
> > On Tue, 27 Jan 2026 at 10:34, Ryan Roberts <[email protected]> wrote:
> >>
> >> On 26/01/2026 09:26, Ard Biesheuvel wrote:
> >>> From: Ard Biesheuvel <[email protected]>
> >>>
> >>> The zero page should contain only zero bytes, and so mapping it
> >>> read-write is unnecessary. Combine it with reserved_pg_dir, which lives
> >>> in the read-only region of the kernel, and already serves a similar
> >>> purpose.
> >>>
> >>> Signed-off-by: Ard Biesheuvel <[email protected]>
> >>> ---
> >>>  arch/arm64/kernel/vmlinux.lds.S | 1 +
> >>>  arch/arm64/mm/mmu.c             | 3 +--
> >>>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm64/kernel/vmlinux.lds.S 
> >>> b/arch/arm64/kernel/vmlinux.lds.S
> >>> index ad6133b89e7a..b2a093f5b3fc 100644
> >>> --- a/arch/arm64/kernel/vmlinux.lds.S
> >>> +++ b/arch/arm64/kernel/vmlinux.lds.S
> >>> @@ -229,6 +229,7 @@ SECTIONS
> >>>  #endif
> >>>
> >>>       reserved_pg_dir = .;
> >>> +     empty_zero_page = .;
> >>>       . += PAGE_SIZE;
> >>>
> >>>       swapper_pg_dir = .;
> >>
> >> Isn't there a magic macro for getting from swapper to reserved? That will 
> >> need
> >> updating?
> >>
> >
> > Why? This just adds an alias to refer to the same allocation.
>
> Oh yes, sorry I completely missed that. And you've even stated it in the 
> commit
> log...
>
> I'm struggling to see where this gets zeroed though? I assume it must be 
> zeroed
> before the old empty_zero_page would have been so everything works fine?
>

It is statically zero initialized in the image.

> Assuming yes, then:
>
> Reviewed-by: Ryan Roberts <[email protected]>
>

Thanks!

Reply via email to