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 E21DCC4345F for ; Mon, 29 Apr 2024 14:19:09 +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:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=amoX0Nib5qIVbRVJBVDuR7RumFz4KmTf0H117++4Th4=; b=DhOyozmaYLtlxw XbVBDwAvw2tVodFrbQP7iICzJsPRew5pPnfjYB9IuORLzkVnMWEVC5qFvpU5aL56ifM8bmV1nF8yh MEa2wmYAIGWgIoMXpvxp+8098iMkfgEIj1ZTV6gEfVPW03romow3XokYX5qCO/VRbjJfCZiftdAsd 2dsYKXJkKHy/DcHeHdmTmS2Nzbx7cqkdSkF1X618gY21pYbX/58YbGlbszXaignIjSoGeptIOegnV hwKyf5H+R/i7rQhyJxIzs9R1m++MH1WVK5yD6Ju4DsbQ4x7d20D/ArEJJorATamDDL8ZZbfj9YRS3 2A2sD73GCxWc1IbTcJnw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1RqK-000000036P5-3h0H; Mon, 29 Apr 2024 14:18:56 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s1RqH-000000036O7-0w9x for linux-arm-kernel@lists.infradead.org; Mon, 29 Apr 2024 14:18:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 505E9CE0C07; Mon, 29 Apr 2024 14:18:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 119BEC113CD; Mon, 29 Apr 2024 14:18:47 +0000 (UTC) Date: Mon, 29 Apr 2024 15:18:45 +0100 From: Catalin Marinas To: Ryan Roberts 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 Subject: Re: [PATCH v1 1/2] arm64/mm: Move PTE_PROT_NONE and PMD_PRESENT_INVALID Message-ID: References: <20240424111017.3160195-1-ryan.roberts@arm.com> <20240424111017.3160195-2-ryan.roberts@arm.com> <3ee07020-74d9-4f13-a3d0-4924a1aa69c6@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3ee07020-74d9-4f13-a3d0-4924a1aa69c6@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240429_071853_639048_DA34F12E X-CRM114-Status: GOOD ( 26.21 ) 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 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). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel