On 20/5/2026 20:16, Ard Biesheuvel wrote:
On Wed, 20 May 2026, at 11:59, Christophe Leroy (CS GROUP) wrote:
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 :
...
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.
Good point. That way, we'll end up with
arch/powerpc/lib/code-patching.c | 52 ++--------------------------------------
1 file changed, 2 insertions(+), 50 deletions(-
I'll spin a v2 with those changes once everyone on cc has had the opportunity
to chime in.
That diffstat is definitely attractive.
I do like that unmap_patch_area() is more defensive with the page table
walk, but it's probably overly paranoid. If page table levels have
vanished since we just mapped them then the system is probably toast anyway.
So OK by me.
cheers
