From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2EDE1C54E5D for ; Tue, 19 Mar 2024 09:43:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 53B6387B77; Tue, 19 Mar 2024 10:43:11 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="bXL64kOw"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7F54B87CFE; Tue, 19 Mar 2024 10:43:10 +0100 (CET) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4F8B88772A for ; Tue, 19 Mar 2024 10:43:08 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=maz@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9B73A60E73; Tue, 19 Mar 2024 09:43:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42507C433C7; Tue, 19 Mar 2024 09:43:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1710841386; bh=F0EfHrqcvozBMCdaffYhFzZzwmIQ2wOv+vwst6mpCQ0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bXL64kOwVZr/R+jK6576ziyvMnjVqQkDjZ+VRCX/A24AhfskXCzgNcHTDmUMyfM9v j/9B0dOSD2d9XZYss8Lni7B3IqP52JyFv94iU50wG1eIVm514H960d2pmW7F/Rh2DL RTddl/LD2CmReyfEUErQWiizVxTCrMttAipLgmHVjUFQjZCNxl0lxeg0n6jF0+Ad2J 4zvwjdH588r+vL+JQpHM4fy03fc/tKUGi1H4czlg0k/hXxeNTRU7zRibLPnbFMh780 /D+4WggylBjPq/Y9/c8n8htCrj0POrWC8DsOpp4IIale2tBT5/fpUaPxbILbhY0Blv MGomAcP3wr8Rg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1rmVzs-00DX82-48; Tue, 19 Mar 2024 09:43:04 +0000 Date: Tue, 19 Mar 2024 09:43:03 +0000 Message-ID: <86o7bazheg.wl-maz@kernel.org> From: Marc Zyngier To: =?UTF-8?B?UGllcnJlLUNsw6ltZW50?= Tosi Cc: u-boot@lists.denx.de, Fabio Estevam , Tom Rini Subject: Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks In-Reply-To: <43haokus4jdxguk4arig5tsqcgq2wbezwpbj7oti6pdkvrfual@wa7vz2iypcv5> References: <43haokus4jdxguk4arig5tsqcgq2wbezwpbj7oti6pdkvrfual@wa7vz2iypcv5> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ptosi@google.com, u-boot@lists.denx.de, festevam@gmail.com, trini@konsulko.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Mon, 18 Mar 2024 19:35:49 +0000, Pierre-Cl=C3=A9ment Tosi wrote: >=20 > The implementation of map_range() creates the requested mapping by > walking the page tables, iterating over multiple PTEs and/or descending > into existing table mappings as needed. When doing so, it assumes any > pre-existing valid PTE to be a table mapping. This assumption is wrong > if the platform code attempts to successively map two overlapping ranges > where the latter intersects a block mapping created for the former. >=20 > As a result, map_range() treats the existing block mapping as a table > mapping and descends into it i.e. starts interpreting the > previously-mapped range as an array of PTEs, writing to them and > potentially even descending further (extra fun with MMIO ranges!). >=20 > Instead, pass any valid non-table mapping to split_block(), which > ensures that it actually was a block mapping (calls panic() otherwise) > before splitting it. >=20 > Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity") > Signed-off-by: Pierre-Cl=C3=A9ment Tosi > --- > arch/arm/cpu/armv8/cache_v8.c | 2 ++ > 1 file changed, 2 insertions(+) >=20 > diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c > index 697334086f..57d06f0575 100644 > --- a/arch/arm/cpu/armv8/cache_v8.c > +++ b/arch/arm/cpu/armv8/cache_v8.c > @@ -326,6 +326,8 @@ static void map_range(u64 virt, u64 phys, u64 size, i= nt level, > /* Going one level down */ > if (pte_type(&table[i]) =3D=3D PTE_TYPE_FAULT) > set_pte_table(&table[i], create_table()); > + else if (pte_type(&table[i]) !=3D PTE_TYPE_TABLE) > + split_block(&table[i], level); > =20 > next_table =3D (u64 *)(table[i] & GENMASK_ULL(47, PAGE_SHIFT)); > next_size =3D min(map_size - (virt & (map_size - 1)), size); This seems pretty reasonable, thanks for looking into this. However, I can't help but notice that this is done without any BBM, and no TLBI either. Are we guaranteed that the updated page tables are not live at the point of update? Thanks, M. --=20 Without deviation from the norm, progress is not possible.