From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29C4C3C0608 for ; Wed, 20 May 2026 09:59:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779271184; cv=none; b=ikYtmlzMb+uJmMjNixACLdlhG5d8NYbiNKzQMkGBpt3NgaKPMGY2qNU3M3N/30rZV03o1uo+4OLMYsjaMfE7VE0XLbBl+bL0tsmA1k3E7j73xlC+xNgnR5DYtGkIeMpKYzj20msmPuOHQOwBTdLJxhdKqWlSdD/NYLkc3s+sVBY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779271184; c=relaxed/simple; bh=CNCcMwAflYWSr5oVXq3fZlVxPqy/h831tvDgZg3rCvk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RSrJ97mI9D0qlB7JvKDYhmTwEa2I34b05o0opYzPHv+ZleucMNRtO8m1fLRli7c4FEjYLrg5qH7rVIwBTgqdN4VMpuXZozxVN8DiunduMBMfrbZQ023UuyPJ1N8W1os40ui4Gu9BkMRjqhaaLsnL4oZE25SizjAZF9ZMql4I/w4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qc7NIX3+; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qc7NIX3+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1ACF1F000E9; Wed, 20 May 2026 09:59:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779271182; bh=p91ID7ZSzXqugYcRdarh8oWFAzscV9Mfd+6vAnBXmOM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=Qc7NIX3+owrcApCTEwgmL7sVS5fJfjitxdcB+v7YDB97Z6I43/IvuFni5msmksvOx CG4zR3Z83/b5ofSitLfBJ+3jb3wTvGCsDHBMqH5aZa3c6OMrmEgAXlsJgVoGU+jABK 1WYFTU35zhYEX1kTf++ob/L3KFx19un/D7gqvuhrlYtyT4+l9JufHREzPtifYHx4fF b1AoSNpx8SMGpYn3/OCtjf7mgDDwwWt4/Ev+jlX4iMfCf2/+Qe7LPJF9+sk0D2FFnP CmD3Lqv8bSgN3oW8GUjX1MiF1qVlo0hQhUyQfI9Yg85F+kHEmKowNFmzTF+AK6+YHp qZuCM6p4HEc3g== Message-ID: <757318e3-91df-4e39-ba44-5130626d38b8@kernel.org> Date: Wed, 20 May 2026 11:59:39 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH resend] powerpc/code-patching: Avoid r/w mapping of the zero page To: Ard Biesheuvel , linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin References: <20260520085423.485402-1-ardb@kernel.org> <3e63e2eb-30b3-4377-9331-41445d9c8720@app.fastmail.com> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: <3e63e2eb-30b3-4377-9331-41445d9c8720@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >>> Cc: Michael Ellerman >>> Cc: Nicholas Piggin >>> Cc: "Christophe Leroy (CS GROUP)" >>> Signed-off-by: Ard Biesheuvel >>> --- >>> 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