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:59:39 +0200 [thread overview]
Message-ID: <757318e3-91df-4e39-ba44-5130626d38b8@kernel.org> (raw)
In-Reply-To: <3e63e2eb-30b3-4377-9331-41445d9c8720@app.fastmail.com>
Le 20/05/2026 à 11:40, Ard Biesheuvel a écrit :
>
> On Wed, 20 May 2026, at 11:36, Christophe Leroy (CS GROUP) wrote:
>> 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);
>>
>
> I think retaining the symmetry of map_patch_area() and unmap_patch_area()
> makes sense too.
Could also drop unmap_patch_area() and use unmap_kernel_page() instead.
>
>>
>> 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")
>>
>
> In the end, it doesn't make any difference, given that the mapping is removed
> again immediately. It is just neater to use _RO to map a const object, rather
> than explicitly creating a read-write mapping of something that should really
> never be written to.
>
Ok
next prev parent reply other threads:[~2026-05-20 9:59 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)
2026-05-20 9:40 ` Ard Biesheuvel
2026-05-20 9:59 ` Christophe Leroy (CS GROUP) [this message]
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=757318e3-91df-4e39-ba44-5130626d38b8@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