LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>, linux-kernel@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page
Date: Wed, 20 May 2026 11:36:44 +0200	[thread overview]
Message-ID: <d4690d12-77d5-4575-9a79-484a919d3203@kernel.org> (raw)
In-Reply-To: <20260520085423.485402-1-ardb@kernel.org>



Le 20/05/2026 à 10:54, Ard Biesheuvel a écrit :
> The only remaining use of map_patch_area() is mapping the zero page, and
> immediately unmapping it again so that the intermediate page table
> levels are all guaranteed to be populated.
> 
> The use of the zero page here is completely arbitrary, and not harmful
> per se, but currently, it creates a writable mapping, and does so in a
> manner that requires that the empty_zero_page[] symbol is not
> const-qualified.
> 
> Given that this is about to change, and that map_patch_area() now never
> maps anything other than the zero page, let's simplify the code and
> - take the PA of empty_zero_page directly
> - create a read-only temporary mapping.
> 
> This allows empty_zero_page[] to be repainted as const u8[] in a
> subsequent patch, without making substantial changes to this code
> patching logic.
> 
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> Build tested only (Clang)
> 
> Resending from my non-Google email. Apologies if you are receiving this
> twice.
> 
>   arch/powerpc/lib/code-patching.c | 11 +++++------
>   1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index f84e0337cc02..13a8acf851f1 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -60,7 +60,7 @@ struct patch_context {
>   
>   static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>   
> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
> +static int map_patch_area(unsigned long text_poke_addr);
>   static void unmap_patch_area(unsigned long addr);
>   
>   static bool mm_patch_enabled(void)
> @@ -117,7 +117,7 @@ static int text_area_cpu_up(unsigned int cpu)
>   
>   	// Map/unmap the area to ensure all page tables are pre-allocated
>   	addr = (unsigned long)area->addr;
> -	err = map_patch_area(empty_zero_page, addr);
> +	err = map_patch_area(addr);

I would get rid of map_patch_area() completely and just do:

	err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);


By the way I don't know how vital it is to map in read-only but in case 
it is see commit da3a3b0a0e38 ("powerpc/32s: map kasan zero shadow with 
PAGE_READONLY instead of PAGE_KERNEL_RO")

>   	if (err)
>   		return err;
>   
> @@ -236,11 +236,10 @@ static unsigned long get_patch_pfn(void *addr)
>   /*
>    * This can be called for kernel text or a module.
>    */
> -static int map_patch_area(void *addr, unsigned long text_poke_addr)
> +static int map_patch_area(unsigned long text_poke_addr)
>   {
> -	unsigned long pfn = get_patch_pfn(addr);
> -
> -	return map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), PAGE_KERNEL);
> +	return map_kernel_page(text_poke_addr, __pa_symbol(empty_zero_page),
> +			       PAGE_KERNEL_RO);
>   }
>   
>   static void unmap_patch_area(unsigned long addr)



  reply	other threads:[~2026-05-20  9:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-20  8:54 [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page Ard Biesheuvel
2026-05-20  9:36 ` Christophe Leroy (CS GROUP) [this message]
2026-05-20  9:40   ` Ard Biesheuvel
2026-05-20  9:59     ` Christophe Leroy (CS GROUP)
2026-05-20 10:16       ` Ard Biesheuvel
2026-05-22  6:51         ` Michael Ellerman

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=d4690d12-77d5-4575-9a79-484a919d3203@kernel.org \
    --to=chleroy@kernel.org \
    --cc=ardb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.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