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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EE65C433EF for ; Mon, 21 Mar 2022 17:44:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350136AbiCURpt (ORCPT ); Mon, 21 Mar 2022 13:45:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238056AbiCURpr (ORCPT ); Mon, 21 Mar 2022 13:45:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 012493AA5B; Mon, 21 Mar 2022 10:44:19 -0700 (PDT) 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 142D4B818D2; Mon, 21 Mar 2022 17:44:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48FE8C340E8; Mon, 21 Mar 2022 17:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647884656; bh=Cc93Sj0aRgEOWTPpRj8NNqcOtJCr+4R/IS5e+PnVDpI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U3fE9mvncxRxT9MkMJyY0wRxVjZfmImW2AWeVMS26K1N5AtfUrZ1VUSp/QbiO/uIR BFbccvvfaSmWp/4TrOWv/MhNpySrnD3IQq3wzid7KyDktnTbLdSYaFOJLcRZtN4o7N aDSP6nZ92OrCdbiQk8QH4DJ9LgjlQ5L1sJF3iyIWFCD3ZQtx29z+angBTrsQGIj6Kn DdRfhByEDboFK2Cl786MKfWBivB0FL5zKRy23ALcA8DH4ljl0HYRhoHyjFQ4aXHahG qSstj/taGkUf/aMOjalkyn48fWLmLB6kIOwvf2k/g0exuPW+jZpFfMOn1uJibIorNR UkF9q9okXpjRg== Date: Mon, 21 Mar 2022 17:44:05 +0000 From: Will Deacon To: David Hildenbrand Cc: Catalin Marinas , 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: <20220321174404.GA11389@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: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 21, 2022 at 04:07:48PM +0100, David Hildenbrand wrote: > On 21.03.22 15:38, 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)); > > Note that __HAVE_ARCH_PTE_SWP_EXCLUSIVE currently only applies to actual > swap entries, not non-swap entries (migration, hwpoison, ...). So it > really only applies to PTEs -- PMDs are not applicable. Right, thanks for the clarification. > So the example you gave cannot possibly have that bit set. From what I > understand, it should be fine. But I have no real preference: I can also > just stick to the original patch, whatever you prefer. I think I'd prefer to stay on the safe side and stick with bit 2 as you originally proposed. If we need to support crazy numbers of swapfiles in future then we can revisit the idea of allocating bit 1. Thanks, and sorry for the trouble. Will 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (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 EC9B4C433FE for ; Mon, 21 Mar 2022 17:45:03 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KMhpQ32rFz3bZv for ; Tue, 22 Mar 2022 04:45:02 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=U3fE9mvn; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=will@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=U3fE9mvn; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KMhnf02Gfz3050 for ; Tue, 22 Mar 2022 04:44:21 +1100 (AEDT) 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 dfw.source.kernel.org (Postfix) with ESMTPS id 51F746147C; Mon, 21 Mar 2022 17:44:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48FE8C340E8; Mon, 21 Mar 2022 17:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647884656; bh=Cc93Sj0aRgEOWTPpRj8NNqcOtJCr+4R/IS5e+PnVDpI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U3fE9mvncxRxT9MkMJyY0wRxVjZfmImW2AWeVMS26K1N5AtfUrZ1VUSp/QbiO/uIR BFbccvvfaSmWp/4TrOWv/MhNpySrnD3IQq3wzid7KyDktnTbLdSYaFOJLcRZtN4o7N aDSP6nZ92OrCdbiQk8QH4DJ9LgjlQ5L1sJF3iyIWFCD3ZQtx29z+angBTrsQGIj6Kn DdRfhByEDboFK2Cl786MKfWBivB0FL5zKRy23ALcA8DH4ljl0HYRhoHyjFQ4aXHahG qSstj/taGkUf/aMOjalkyn48fWLmLB6kIOwvf2k/g0exuPW+jZpFfMOn1uJibIorNR UkF9q9okXpjRg== Date: Mon, 21 Mar 2022 17:44:05 +0000 From: Will Deacon To: David Hildenbrand Subject: Re: [PATCH v1 4/7] arm64/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE Message-ID: <20220321174404.GA11389@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: User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: x86@kernel.org, Jan Kara , Catalin Marinas , Yang Shi , Dave Hansen , Peter Xu , Michal Hocko , linux-mm@kvack.org, Nadav Amit , Liang Zhang , Borislav Petkov , Alexander Gordeev , Christoph Hellwig , Paul Mackerras , Andrea Arcangeli , linux-s390@vger.kernel.org, Vasily Gorbik , Rik van Riel , Hugh Dickins , Matthew Wilcox , Mike Rapoport , Ingo Molnar , linux-arm-kernel@lists.infradead.org, Jason Gunthorpe , David Rientjes , Pedro Gomes , Jann Horn , John Hubbard , Heiko Carstens , Shakeel Butt , Oleg Nesterov , Thomas Gleixner , Vlastimil Babka , Oded Gabbay , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Donald Dutile , Andrew Morton , Linus Torvalds , Roman Gushchin , "Kirill A . Shutemov" , Mike Kravetz Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Mon, Mar 21, 2022 at 04:07:48PM +0100, David Hildenbrand wrote: > On 21.03.22 15:38, 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)); > > Note that __HAVE_ARCH_PTE_SWP_EXCLUSIVE currently only applies to actual > swap entries, not non-swap entries (migration, hwpoison, ...). So it > really only applies to PTEs -- PMDs are not applicable. Right, thanks for the clarification. > So the example you gave cannot possibly have that bit set. From what I > understand, it should be fine. But I have no real preference: I can also > just stick to the original patch, whatever you prefer. I think I'd prefer to stay on the safe side and stick with bit 2 as you originally proposed. If we need to support crazy numbers of swapfiles in future then we can revisit the idea of allocating bit 1. Thanks, and sorry for the trouble. Will 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 AAA06C433EF for ; Mon, 21 Mar 2022 17:45:36 +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=wpvt0ClCZGMgOFqGaol6UqyvDoh74CAIt60hTihnxDs=; b=jysCgGNIKuSbBc XRAE8PnIHieQDUrRpYAdOwhqmIJUHaJKeIDTzy2Ps9K8sUoQiY3MGd0VMJXkbcJqmOBu7SPCG2QvY CjJQE1ldl4eyDv+zLUP7wid55be1RUyloWeCFjO9VpylmufmHc2NrYWiJoIVzquTduIiQH0bhWZxI pm0S+Vj8s5SLVDxQpHo60dwcyWuxaoZv+nkJ8z2ermlKkXvpYLnCJsOpiUGwagA5QtqYhRhyOmGbt Qq2CucAvnTuwyB6eVTMhe0bJduC0rzaGJAAWYz+4hDLe4F8E2HAKsVEA209BEJ0g6yjfGTiiJjVGb KlfhatThDBEQ3lD+LBOw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWM4r-008eof-Hh; Mon, 21 Mar 2022 17:44:21 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nWM4n-008ena-TU for linux-arm-kernel@lists.infradead.org; Mon, 21 Mar 2022 17:44:19 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id 51F746147C; Mon, 21 Mar 2022 17:44:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48FE8C340E8; Mon, 21 Mar 2022 17:44:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1647884656; bh=Cc93Sj0aRgEOWTPpRj8NNqcOtJCr+4R/IS5e+PnVDpI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U3fE9mvncxRxT9MkMJyY0wRxVjZfmImW2AWeVMS26K1N5AtfUrZ1VUSp/QbiO/uIR BFbccvvfaSmWp/4TrOWv/MhNpySrnD3IQq3wzid7KyDktnTbLdSYaFOJLcRZtN4o7N aDSP6nZ92OrCdbiQk8QH4DJ9LgjlQ5L1sJF3iyIWFCD3ZQtx29z+angBTrsQGIj6Kn DdRfhByEDboFK2Cl786MKfWBivB0FL5zKRy23ALcA8DH4ljl0HYRhoHyjFQ4aXHahG qSstj/taGkUf/aMOjalkyn48fWLmLB6kIOwvf2k/g0exuPW+jZpFfMOn1uJibIorNR UkF9q9okXpjRg== Date: Mon, 21 Mar 2022 17:44:05 +0000 From: Will Deacon To: David Hildenbrand Cc: Catalin Marinas , 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: <20220321174404.GA11389@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-Disposition: inline In-Reply-To: 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-20220321_104418_073258_FF01990C X-CRM114-Status: GOOD ( 31.89 ) 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, Mar 21, 2022 at 04:07:48PM +0100, David Hildenbrand wrote: > On 21.03.22 15:38, 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)); > > Note that __HAVE_ARCH_PTE_SWP_EXCLUSIVE currently only applies to actual > swap entries, not non-swap entries (migration, hwpoison, ...). So it > really only applies to PTEs -- PMDs are not applicable. Right, thanks for the clarification. > So the example you gave cannot possibly have that bit set. From what I > understand, it should be fine. But I have no real preference: I can also > just stick to the original patch, whatever you prefer. I think I'd prefer to stay on the safe side and stick with bit 2 as you originally proposed. If we need to support crazy numbers of swapfiles in future then we can revisit the idea of allocating bit 1. Thanks, and sorry for the trouble. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel