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 8D218C4332F for ; Thu, 8 Dec 2022 08:56:53 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4NSSh40gr9z3bVW for ; Thu, 8 Dec 2022 19:56:52 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QPFkG++A; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QPFkG++A; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=redhat.com (client-ip=170.10.129.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=david@redhat.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QPFkG++A; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=QPFkG++A; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4NSSg20j3Pz2xHJ for ; Thu, 8 Dec 2022 19:55:57 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670489755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qZzQND0XXn/ac1VVVRiwKzVF2wPIGejtH8QPoB1hHfA=; b=QPFkG++A/8JL5La+pALQpMxgOwAt4ktwVCkc0B7GKmSOmsQdJwO6bUe02qtZHfivaxVdc3 G9Wjgdcy6CTAaGzTr8Cckc2sdx+1EbdNMrC++y5ZAPBbYS5RMOrBZy9yOPYliW8bDkf1S/ 1Ay3qqX5PGov4onlFtRbv5LxaYRg05Q= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670489755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qZzQND0XXn/ac1VVVRiwKzVF2wPIGejtH8QPoB1hHfA=; b=QPFkG++A/8JL5La+pALQpMxgOwAt4ktwVCkc0B7GKmSOmsQdJwO6bUe02qtZHfivaxVdc3 G9Wjgdcy6CTAaGzTr8Cckc2sdx+1EbdNMrC++y5ZAPBbYS5RMOrBZy9yOPYliW8bDkf1S/ 1Ay3qqX5PGov4onlFtRbv5LxaYRg05Q= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-177-WVFmO68kPsm5N1LUZaICaA-1; Thu, 08 Dec 2022 03:55:54 -0500 X-MC-Unique: WVFmO68kPsm5N1LUZaICaA-1 Received: by mail-wm1-f71.google.com with SMTP id bi19-20020a05600c3d9300b003cf9d6c4016so2102678wmb.8 for ; Thu, 08 Dec 2022 00:55:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:references:cc:to :from:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qZzQND0XXn/ac1VVVRiwKzVF2wPIGejtH8QPoB1hHfA=; b=Of3D9OGgm5XxXo1CYEYKgNbdSUzTuHwTi5CbmWirRXF6HzZLPZtLmD86ouhcHiNDcG fOXm0HTtebBz5qljkVlvq3MR4iHZXFZTykfU+7fGyF9h5721X/EFz5BOpFxK5+cXNRhR 4wrkrAh5bJ/9G/p/RZ5A3vqXHVk+dia5q9RkUCM0tzRRF4W2LDPSm7QmyPckE4ob0Bxv 975ql3tmrU2sYScvmkr0Yo4EEe+Td/8tVhXtjjbFzmup4j16YL+r80XqFZqgA4CQ4EBF Ypj2TDNMx/0oa/C/jHfmvdvFm6ipWy3BuXWM9FX6UBT+kjih4Jo08BWQrZckWtHpySpN 3uwQ== X-Gm-Message-State: ANoB5pnKYBiDHXPA41UpI5vbsFwU4oaASNBcXRRHAkvxQqELifauqUD1 Bjp39cbH5LbHFwZClfyrSOASBsxML6ZkganoNzZxfLoPCxIDYspUZyDAC97Oisc8YuujBeZrRRQ 5JEgbWtb9pVRcMrFxUgTlQMjKBg== X-Received: by 2002:a5d:504d:0:b0:242:246c:2f89 with SMTP id h13-20020a5d504d000000b00242246c2f89mr22919595wrt.108.1670489752974; Thu, 08 Dec 2022 00:55:52 -0800 (PST) X-Google-Smtp-Source: AA0mqf668NfxbMXQWSDBD6iCzqqUG4mJSCJROvTfbJs0ERpg3lPeZTVH/8wev7o0MHbpIs1xArxqSg== X-Received: by 2002:a5d:504d:0:b0:242:246c:2f89 with SMTP id h13-20020a5d504d000000b00242246c2f89mr22919565wrt.108.1670489752626; Thu, 08 Dec 2022 00:55:52 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id o29-20020adfa11d000000b0024278304ef6sm6288982wro.13.2022.12.08.00.55.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Dec 2022 00:55:52 -0800 (PST) Message-ID: Date: Thu, 8 Dec 2022 09:55:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH mm-unstable RFC 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s From: David Hildenbrand To: Christophe Leroy , "linux-kernel@vger.kernel.org" References: <20221206144730.163732-1-david@redhat.com> <20221206144730.163732-18-david@redhat.com> <8be167b6-3836-25c3-9f69-b8b3916ee5b4@csgroup.eu> <0b5b1303-8bcb-c19d-5f63-0e4a3517fea5@redhat.com> Organization: Red Hat In-Reply-To: <0b5b1303-8bcb-c19d-5f63-0e4a3517fea5@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , Yang Shi , Peter Xu , "linux-mm@kvack.org" , Nadav Amit , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , Andrea Arcangeli , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "x86@kernel.org" , Hugh Dickins , "linux-csky@vger.kernel.org" , Mike Rapoport , Vlastimil Babka , Jason Gunthorpe , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , John Hubbard , "linux-um@lists.infradead.org" , Nicholas Piggin , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "loongarch@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-alpha@vger.kernel.org" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 08.12.22 09:52, David Hildenbrand wrote: > On 07.12.22 14:55, Christophe Leroy wrote: >> >> >> Le 06/12/2022 à 15:47, David Hildenbrand a écrit : >>> We already implemented support for 64bit book3s in commit bff9beaa2e80 >>> ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s") >>> >>> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet >>> unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot >>> be used, and reusing it avoids having to steal one bit from the swap >>> offset. >>> >>> While at it, mask the type in __swp_entry(). >>> >>> Cc: Michael Ellerman >>> Cc: Nicholas Piggin >>> Cc: Christophe Leroy >>> Signed-off-by: David Hildenbrand >>> --- >>> arch/powerpc/include/asm/book3s/32/pgtable.h | 38 +++++++++++++++++--- >>> 1 file changed, 33 insertions(+), 5 deletions(-) >>> >>> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h b/arch/powerpc/include/asm/book3s/32/pgtable.h >>> index 75823f39e042..8107835b38c1 100644 >>> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h >>> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h >>> @@ -42,6 +42,9 @@ >>> #define _PMD_PRESENT_MASK (PAGE_MASK) >>> #define _PMD_BAD (~PAGE_MASK) >>> >>> +/* We borrow the _PAGE_USER bit to store the exclusive marker in swap PTEs. */ >>> +#define _PAGE_SWP_EXCLUSIVE _PAGE_USER >>> + >>> /* And here we include common definitions */ >>> >>> #define _PAGE_KERNEL_RO 0 >>> @@ -363,17 +366,42 @@ static inline void __ptep_set_access_flags(struct vm_area_struct *vma, >>> #define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd)) >>> >>> /* >>> - * Encode and decode a swap entry. >>> - * Note that the bits we use in a PTE for representing a swap entry >>> - * must not include the _PAGE_PRESENT bit or the _PAGE_HASHPTE bit (if used). >>> - * -- paulus >>> + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that >>> + * are !pte_none() && !pte_present(). >>> + * >>> + * Format of swap PTEs (32bit PTEs): >>> + * >>> + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 >>> + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> + * E H P <- type --> <----------------- offset ------------------> >> >> That's in reversed order. _PAGE_HASHPTE is bit 30 and should be on the >> right hand side. Etc ... > > Ugh, messed it up while converting back and forth between LSB 0 and MSB 0. > > /* > * Format of swap PTEs (32bit PTEs): > * > * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 > * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > * <----------------- offset ------------------> <- type --> E H P > > Still wrong, the type is only 5 bits: + * Format of swap PTEs (32bit PTEs): + * + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + * <----------------- offset --------------------> < type -> E H P + * -- Thanks, David / dhildenb