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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78676C433EF for ; Mon, 21 Mar 2022 14:39:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E8646B0071; Mon, 21 Mar 2022 10:39:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 098686B0072; Mon, 21 Mar 2022 10:39:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA1C56B0074; Mon, 21 Mar 2022 10:39:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id DDDFB6B0071 for ; Mon, 21 Mar 2022 10:39:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id AFF83236B8 for ; Mon, 21 Mar 2022 14:39:58 +0000 (UTC) X-FDA: 79268652876.04.4EEC352 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id 1ADC24000A for ; Mon, 21 Mar 2022 14:39:57 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id CD73FB8170E; Mon, 21 Mar 2022 14:39:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06D4EC340E8; Mon, 21 Mar 2022 14:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647873595; bh=DvATwoHTxnArnbHtADD5Mg71Fi3pHjfQ9J9ORoxi+UI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NYmgDU7FL+wbRjIgi+f4VRnRmFWuAVTkl7g3kOamPyLk64U7Ax14VO3SKbCcdbC0W Bu9cW7deMtVw3T9rWU9seP7toK06zScpQrc2iTe/0KTcA24G/CBgcGsaI2DXLcBtSS ofo0rT/LwpSJdn0mJVwpa2dzNYgcP03+DZc32HeKsxMcy4TvJk7IWLgPLjvLaDUWBQ bAUN+fbbDqXv/lYRyuXk/5NpPINOtFu8yiE1SLqeC5w3HqTeDdltRxgES82G62Oo0R qpOpLHCTH3K/Egvs2irmRYrKOdTEosWJmRJXwzhj0xH6E7NYv0RvaKXlvX642pbZ0x jNQ9DhNE8HAsQ== Date: Mon, 21 Mar 2022 14:39:44 +0000 From: Will Deacon To: Catalin Marinas Cc: David Hildenbrand , linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , linux-mm@kvack.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org Subject: Re: [PATCH v1 4/7] arm64/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE Message-ID: <20220321143944.GD11145@willie-the-truck> References: <20220315141837.137118-1-david@redhat.com> <20220315141837.137118-5-david@redhat.com> <20220321143802.GC11145@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220321143802.GC11145@willie-the-truck> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Queue-Id: 1ADC24000A X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=NYmgDU7F; spf=pass (imf04.hostedemail.com: domain of will@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=will@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: nyypm5hz98agwb8au1zdfm7jzpe31op1 X-Rspamd-Server: rspam07 X-HE-Tag: 1647873597-833323 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Mar 21, 2022 at 02:38:02PM +0000, Will Deacon wrote: > On Wed, Mar 16, 2022 at 06:27:01PM +0000, Catalin Marinas wrote: > > On Tue, Mar 15, 2022 at 03:18:34PM +0100, David Hildenbrand wrote: > > > diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h > > > index b1e1b74d993c..62e0ebeed720 100644 > > > --- a/arch/arm64/include/asm/pgtable-prot.h > > > +++ b/arch/arm64/include/asm/pgtable-prot.h > > > @@ -14,6 +14,7 @@ > > > * Software defined PTE bits definition. > > > */ > > > #define PTE_WRITE (PTE_DBM) /* same as DBM (51) */ > > > +#define PTE_SWP_EXCLUSIVE (_AT(pteval_t, 1) << 2) /* only for swp ptes */ > > > > I think we can use bit 1 here. > > > > > @@ -909,12 +925,13 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma, > > > /* > > > * Encode and decode a swap entry: > > > * bits 0-1: present (must be zero) > > > - * bits 2-7: swap type > > > + * bits 2: remember PG_anon_exclusive > > > + * bits 3-7: swap type > > > * bits 8-57: swap offset > > > * bit 58: PTE_PROT_NONE (must be zero) > > > > I don't remember exactly why we reserved bits 0 and 1 when, from the > > hardware perspective, it's sufficient for bit 0 to be 0 and the whole > > pte becomes invalid. We use bit 1 as the 'table' bit (when 0 at pmd > > level, it's a huge page) but we shouldn't check for this on a swap > > entry. > > I'm a little worried that when we're dealing with huge mappings at the > PMD level we might lose the ability to distinguish them from a pte-level > mapping with this new flag set if we use bit 1. A similar issue to this > was fixed a long time ago by 59911ca4325d ("ARM64: mm: Move PTE_PROT_NONE > bit") when we used to use bit 1 for PTE_PROT_NONE. > > Is something like: > > pmd_to_swp_entry(swp_entry_to_pmd(pmd)); > > supposed to preserve the original pmd? I'm not sure that's guaranteed > after this change if bit 1 can be cleared in the process -- we could end > up with a pte, which the hardware would interpret as a table entry and > end up with really bad things happening. (I got this back to front: having the bit set rather than cleared would be an issue, but the overall point remains). Will