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 A5A0BC19F53 for ; Mon, 29 Apr 2024 15:05:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=r4Xvw08uwfo1D3rCZ3ytSvqM3F+zYsgYneDkJ6Di2rE=; b=EcJsOVjo7mKVld aKulVHZfyyy3kJS2tUuzhm7uPXu5RNuZ6ahlA+cU/3n25naoEtsJvurhHed2Agb39Xce2GdMyxD75 6ziR85NDU3yodYsvdNxcRECs0Vw9bLuonF+S/pHbW7pKrQMmj90fKNpFiuIRIqEGFbQ0Q/2E+WYMy HOGJSgYKDSCqr87wbR5n0xY+rtcROSbKgUa8U9TcXIA1e/u78xAAX7kVRgmzxcY6aKHA6/DyiZ47q 0EunFxUXn1t8Z+kfPbkawy/qSbpDIDpDVa3O73/FPOz/MHtEljGzQAWki4Ld5DD/aUos9w2KdkGZP P7hO/iDxp/FfYVDGfhYw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1SZH-00000003Fju-1GPX; Mon, 29 Apr 2024 15:05:23 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1SYf-00000003FFl-1bkI for linux-arm-kernel@lists.infradead.org; Mon, 29 Apr 2024 15:04:48 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 77E312F4; Mon, 29 Apr 2024 08:05:09 -0700 (PDT) Received: from [10.57.65.53] (unknown [10.57.65.53]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2946E3F793; Mon, 29 Apr 2024 08:04:41 -0700 (PDT) Message-ID: <5ea44a93-08a8-4385-b684-bf6fcd007bfb@arm.com> Date: Mon, 29 Apr 2024 16:04:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] arm64/mm: Move PTE_PROT_NONE and PMD_PRESENT_INVALID Content-Language: en-GB To: Catalin Marinas Cc: David Hildenbrand , Will Deacon , Joey Gouly , Ard Biesheuvel , Mark Rutland , Anshuman Khandual , Peter Xu , Mike Rapoport , Shivansh Vij , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20240424111017.3160195-1-ryan.roberts@arm.com> <20240424111017.3160195-2-ryan.roberts@arm.com> <3ee07020-74d9-4f13-a3d0-4924a1aa69c6@arm.com> From: Ryan Roberts In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240429_080445_584537_94AF23CC X-CRM114-Status: GOOD ( 19.66 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 29/04/2024 15:18, Catalin Marinas wrote: > On Mon, Apr 29, 2024 at 02:23:35PM +0100, Ryan Roberts wrote: >> On 29/04/2024 14:01, Ryan Roberts wrote: >>> On 29/04/2024 13:38, Catalin Marinas wrote: >>>> On Mon, Apr 29, 2024 at 11:04:53AM +0100, Ryan Roberts wrote: >>>>> On 26/04/2024 15:48, Catalin Marinas wrote: >>>>>> On Thu, Apr 25, 2024 at 11:37:42AM +0100, Ryan Roberts wrote: >>>>>>> Also, IMHO we shouldn't really need to reserve PMD_PRESENT_INVALID for swap >>>>>>> ptes; it would be cleaner to have one bit that defines "present" when valid is >>>>>>> clear (similar to PTE_PROT_NONE today) then another bit which is only defined >>>>>>> when "present && !valid" which tells us if this is PTE_PROT_NONE or >>>>>>> PMD_PRESENT_INVALID (I don't think you can ever have both at the same time?). >>>>>> >>>>>> I think this make sense, maybe rename the above to PTE_PRESENT_INVALID >>>>>> and use it for both ptes and pmds. >>>>> >>>>> Yep, sounds good. I've already got a patch to do this, but it's exposed a bug in >>>>> core-mm so will now fix that before I can validate my change. see >>>>> https://lore.kernel.org/linux-arm-kernel/ZiuyGXt0XWwRgFh9@x1n/ >>>>> >>>>> With this in place, I'm proposing to remove PTE_PROT_NONE entirely and instead >>>>> represent PROT_NONE as a present but invalid pte (PTE_VALID=0, PTE_INVALID=1) >>>>> with both PTE_WRITE=0 and PTE_RDONLY=0. >>>>> >>>>> While the HW would interpret PTE_WRITE=0/PTE_RDONLY=0 as "RW without dirty bit >>>>> modification", this is not a problem as the pte is invalid, so the HW doesn't >>>>> interpret it. And SW always uses the PTE_WRITE bit to interpret the writability >>>>> of the pte. So PTE_WRITE=0/PTE_RDONLY=0 was previously an unused combination >>>>> that we now repurpose for PROT_NONE. >>>> >>>> Why not just keep the bits currently in PAGE_NONE (PTE_RDONLY would be >>>> set) and check PTE_USER|PTE_UXN == 0b01 which is a unique combination >>>> for PAGE_NONE (bar the kernel mappings). >>> >>> Yes I guess that works. I personally prefer my proposal because it is more >>> intuitive; you have an R bit and a W bit, and you encode RO, WR, and NONE. But >>> if you think reusing the kernel mapping check (PTE_USER|PTE_UXN == 0b01) is >>> preferable, then I'll go with that. >> >> Ignore this - I looked at your proposed approach and agree it's better. I'll use >> `PTE_USER|PTE_UXN==0b01`. Posting shortly... > > You nearly convinced me until I read your second reply ;). The > PTE_WRITE|PTE_RDONLY == 0b00 still has the mkwrite problem if we care > about (I don't think it can happen though). Yes, just to clearly enumerate the reasons I prefer your approach: - PTE_RDONLY is also used for HW dirty bit. I had to add a conditional to pte_mkclean() for my scheme to prevent pte_mkclean() on a PROT_NONE pte eroneously making it RO. No such problem with your scheme. - With my scheme, we have the mkwrite problem, as you call it. Although, as I said some arches already have this semantic, so I don't think its a problem. But with your scheme we keep the existing arm64 semantics so it reduces risk of a problem in a corner I overlooked. Anyway, I've posted the v2. Take a look when you get time - perhaps we can get it into v6.10? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel