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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1E40CC3DA64 for ; Thu, 1 Aug 2024 11:35:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=lmDm3QYl6YqagnOpbZskE7Aj/ZNFz2hv1VOZMLPp39s=; b=eQ2AwZ5ocexsNH+HWbbrswqd46 uC6vsHmEh2XHvqtNggv3uBUma3FV8I3jdozpnOrxEtF4IheJSUZCdcrtrJYDIM0N6B/faXBr7bJvy usge0NKCEzIzfq8t81CEJjKfUGQMgQZJ7VrTOMKSVAneJK5NedamaSZxpCwnr9IbGTHJ5b0qIJ1pR 09pswkFyfUdReJT09fFgSPwnivNM0ljJo0FTK/SEov9S1a35p16EUal/E8wOjcR4kSzZBnJCgWmqe ZH1pZeyno2hqVEV0ahXerW/xrJp7zK2Q68rRvVLq483se4YAjL+hBzInLLDb/Ni+IxyPaqYmB0DSu kmmMn02g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZU5U-00000004w6Z-0DVK; Thu, 01 Aug 2024 11:35:16 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZU50-00000004vwn-1SwT for linux-arm-kernel@lists.infradead.org; Thu, 01 Aug 2024 11:34:47 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id C61EE627CD; Thu, 1 Aug 2024 11:34:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BC23C32786; Thu, 1 Aug 2024 11:34:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722512085; bh=wWd9g3zIcfY15cDSHDDrQHJzRZeFP2sDNPFuFyjKKv0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=K9p8dZ7iHs2NVwjzzVE7/qqHJJkxLiJp6clKYWcE2VA+i1LWhq/JdhS5jsRR9RTkt j4DJY1624XMbT+ElkSyhIQSnjJcEM6qlMR95HTSb8AbEf3WfFUMjp/RN0GKhS1N7RI a13XGcpbH2StJX7ESa42+uEYNeVQftLbepJzXPN9pzUByb8DMxScmVmhM7K2oiVjz6 Vx9R3bmkjHlo2FhA4ZVwFauKl0N2KdEZcIcWNah67wPVYT/FSEYjgdnDAflsg7Op/i WEfMWv4L9iuPj9XpeapC4r/HflBeESmEsi5AKeu/kJhfXGrho4g1LO89kagtPvACxk 6WtiDuBjQB9Kw== Date: Thu, 1 Aug 2024 12:34:41 +0100 From: Will Deacon To: Ryan Roberts Cc: Anshuman Khandual , linux-arm-kernel@lists.infradead.org, Catalin Marinas , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm: Avoid direct referencing page table enties in map_range() Message-ID: <20240801113440.GB4476@willie-the-truck> References: <20240725091052.314750-1-anshuman.khandual@arm.com> <3e82687a-0183-42f3-b32c-6d99dbd4fe49@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e82687a-0183-42f3-b32c-6d99dbd4fe49@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240801_043446_450102_F2BB31A0 X-CRM114-Status: GOOD ( 14.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 25, 2024 at 11:36:56AM +0100, Ryan Roberts wrote: > On 25/07/2024 10:10, Anshuman Khandual wrote: > > Like else where in arm64 platform, use WRITE_ONCE() in map_range() while > > creating page table entries. This avoids referencing page table entries > > directly. > > I could be wrong, but I don't think this code is ever operating on live > pgtables? So there is never a potential to race with the HW walker and therefore > no need to guarrantee copy atomicity? As long as the correct barriers are placed > at the point where you load the pgdir into the TTBRx there should be no problem? > > If my assertion is correct, I don't think there is any need for this change. Agreed. Will