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 95C63C4321E for ; Wed, 9 Mar 2022 11:33:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232410AbiCILew (ORCPT ); Wed, 9 Mar 2022 06:34:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232346AbiCILeu (ORCPT ); Wed, 9 Mar 2022 06:34:50 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 67BB641F8E; Wed, 9 Mar 2022 03:33:40 -0800 (PST) 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 C45AC1655; Wed, 9 Mar 2022 03:33:39 -0800 (PST) Received: from [10.163.33.203] (unknown [10.163.33.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3A213FA4D; Wed, 9 Mar 2022 03:33:29 -0800 (PST) Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> Date: Wed, 9 Mar 2022 17:03:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Content-Language: en-US To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On 3/2/22 16:44, Geert Uytterhoeven wrote: > Hi Anshuman, > > On Wed, Mar 2, 2022 at 12:07 PM Anshuman Khandual > wrote: >> On 3/2/22 3:35 PM, Geert Uytterhoeven wrote: >>> On Wed, Mar 2, 2022 at 10:51 AM Anshuman Khandual >>> wrote: >>>> On 3/2/22 12:35 PM, Christophe Leroy wrote: >>>>> Le 02/03/2022 à 04:22, Anshuman Khandual a écrit : >>>>>> On 3/1/22 1:46 PM, Christophe Leroy wrote: >>>>>>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >>>>>>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>>>>>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>>>>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>>>>>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>>>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>>>>>>>> macros can be dropped which are no longer needed. >>>>>>>>>> >>>>>>>>>> What I would really like to know is why having to run _code_ to work out >>>>>>>>>> what the page protections need to be is better than looking it up in a >>>>>>>>>> table. >>>>>>>>>> >>>>>>>>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>>>>>>>> additional code size with it. >>>>>>>>>> >>>>>>>>>> I'm struggling to see what the benefit is. >>>>>>>>> >>>>>>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>>>>>>>> protection values. Although that is being run in the core MM and from a >>>>>>>>> platform perspective __SXXX, __PXXX are just being exported for a table. >>>>>>>>> Looking it up in a table (and applying more constructs there after) is >>>>>>>>> not much different than a clean switch case statement in terms of CPU >>>>>>>>> usage. So this is not more expensive in terms of CPU cycles. >>>>>>>> >>>>>>>> I disagree. >>>>>>> >>>>>>> So do I. >>>>>>> >>>>>>>> >>>>>>>> However, let's base this disagreement on some evidence. Here is the >>>>>>>> present 32-bit ARM implementation: >>>>>>>> >>>>>>>> 00000048 : >>>>>>>> 48: e200000f and r0, r0, #15 >>>>>>>> 4c: e3003000 movw r3, #0 >>>>>>>> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >>>>>>>> 50: e3403000 movt r3, #0 >>>>>>>> 50: R_ARM_MOVT_ABS .LANCHOR1 >>>>>>>> 54: e7930100 ldr r0, [r3, r0, lsl #2] >>>>>>>> 58: e12fff1e bx lr >>>>>>>> >>>>>>>> That is five instructions long. >>>>>>> >>>>>>> On ppc32 I get: >>>>>>> >>>>>>> 00000094 : >>>>>>> 94: 3d 20 00 00 lis r9,0 >>>>>>> 96: R_PPC_ADDR16_HA .data..ro_after_init >>>>>>> 98: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> 9c: 39 29 00 00 addi r9,r9,0 >>>>>>> 9e: R_PPC_ADDR16_LO .data..ro_after_init >>>>>>> a0: 7d 29 20 2e lwzx r9,r9,r4 >>>>>>> a4: 91 23 00 00 stw r9,0(r3) >>>>>>> a8: 4e 80 00 20 blr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please show that your new implementation is not more expensive on >>>>>>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >>>>>>>> the disassembly. >>>>>>> >>>>>>> With your series I get: >>>>>>> >>>>>>> 00000000 : >>>>>>> 0: 3d 20 00 00 lis r9,0 >>>>>>> 2: R_PPC_ADDR16_HA .rodata >>>>>>> 4: 39 29 00 00 addi r9,r9,0 >>>>>>> 6: R_PPC_ADDR16_LO .rodata >>>>>>> 8: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> c: 7d 49 20 2e lwzx r10,r9,r4 >>>>>>> 10: 7d 4a 4a 14 add r10,r10,r9 >>>>>>> 14: 7d 49 03 a6 mtctr r10 >>>>>>> 18: 4e 80 04 20 bctr >>>>>>> 1c: 39 20 03 15 li r9,789 >>>>>>> 20: 91 23 00 00 stw r9,0(r3) >>>>>>> 24: 4e 80 00 20 blr >>>>>>> 28: 39 20 01 15 li r9,277 >>>>>>> 2c: 91 23 00 00 stw r9,0(r3) >>>>>>> 30: 4e 80 00 20 blr >>>>>>> 34: 39 20 07 15 li r9,1813 >>>>>>> 38: 91 23 00 00 stw r9,0(r3) >>>>>>> 3c: 4e 80 00 20 blr >>>>>>> 40: 39 20 05 15 li r9,1301 >>>>>>> 44: 91 23 00 00 stw r9,0(r3) >>>>>>> 48: 4e 80 00 20 blr >>>>>>> 4c: 39 20 01 11 li r9,273 >>>>>>> 50: 4b ff ff d0 b 20 >>>>>>> >>>>>>> >>>>>>> That is definitely more expensive, it implements a table of branches. >>>>>> >>>>>> Okay, will split out the PPC32 implementation that retains existing >>>>>> table look up method. Also planning to keep that inside same file >>>>>> (arch/powerpc/mm/mmap.c), unless you have a difference preference. >>>>> >>>>> My point was not to get something specific for PPC32, but to amplify on >>>>> Russell's objection. >>>>> >>>>> As this is bad for ARM and bad for PPC32, do we have any evidence that >>>>> your change is good for any other architecture ? >>>>> >>>>> I checked PPC64 and there is exactly the same drawback. With the current >>>>> implementation it is a small function performing table read then a few >>>>> adjustment. After your change it is a bigger function implementing a >>>>> table of branches. >>>> >>>> I am wondering if this would not be the case for any other switch case >>>> statement on the platform ? Is there something specific/different just >>>> on vm_get_page_prot() implementation ? Are you suggesting that switch >>>> case statements should just be avoided instead ? >>>> >>>>> >>>>> So, as requested by Russell, could you look at the disassembly for other >>>>> architectures and show us that ARM and POWERPC are the only ones for >>>>> which your change is not optimal ? >>>> >>>> But the primary purpose of this series is not to guarantee optimized >>>> code on platform by platform basis, while migrating from a table based >>>> look up method into a switch case statement. >>>> >>>> But instead, the purposes is to remove current levels of unnecessary >>>> abstraction while converting a vm_flags access combination into page >>>> protection. The switch case statement for platform implementation of >>>> vm_get_page_prot() just seemed logical enough. Christoph's original >>>> suggestion patch for x86 had the same implementation as well. >>>> >>>> But if the table look up is still better/preferred method on certain >>>> platforms like arm or ppc32, will be happy to preserve that. >>> >>> I doubt the switch() variant would give better code on any platform. >>> >>> What about using tables everywhere, using designated initializers >>> to improve readability? >> >> Designated initializers ? Could you please be more specific. A table look >> up on arm platform would be something like this and arm_protection_map[] >> needs to be updated with user_pgprot like before. Just wondering how a >> designated initializer will help here. > > It's more readable than the original: > > pgprot_t protection_map[16] __ro_after_init = { > __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, > __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 > }; > >> >> static pgprot_t arm_protection_map[16] __ro_after_init = { >> [VM_NONE] = __PAGE_NONE, >> [VM_READ] = __PAGE_READONLY, >> [VM_WRITE] = __PAGE_COPY, >> [VM_WRITE | VM_READ] = __PAGE_COPY, >> [VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC, >> [VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC, >> [VM_SHARED] = __PAGE_NONE, >> [VM_SHARED | VM_READ] = __PAGE_READONLY, >> [VM_SHARED | VM_WRITE] = __PAGE_SHARED, >> [VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED, >> [VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC >> }; > > Yeah, like that. > > Seems like you already made such a conversion in > https://lore.kernel.org/all/1645425519-9034-3-git-send-email-anshuman.khandual@arm.com/ Will rework the series in two different phases as mentioned on the other thread. 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 9761DC433FE for ; Wed, 9 Mar 2022 11:34:00 +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=e8zZLpUeyP3RCy/PyuqYCmzl7LnY7Me2ZiFZSvZ6fF0=; b=lUd8Yy6leGtYNV no7LhtH7CUzIbvx5/yIasBk7d/x7+JKry3pfWXDi2a+BcfWv17XqM/Bea8ZUP3VlD4TIGu6veZAwj Xgx0WDWYZ63IR2fozlAKnapbLUC3TsbP28MLErGoZaicMfqAy9NmsLer6ZH9yZgOmorBjdh/li8Jg I/jNUN6zE1sEO54EfSapH6cMPr1Tbjv+o+Xnyz3lklePdnfN3IbbjWHQh2Plttzgz9HAMGPlLEtfH q3MhR9eCPgJAcRqXD53aI1tYgAYoKK41wHvrLPIiXx/iMGiCPvhKfF/+xU7Ra2it/UAsgohVkG1H/ 6c0FQKjc/7+a1B6SC2nw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZq-008Isw-DN; Wed, 09 Mar 2022 11:33:58 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZY-008Inh-NB; Wed, 09 Mar 2022 11:33:42 +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 C45AC1655; Wed, 9 Mar 2022 03:33:39 -0800 (PST) Received: from [10.163.33.203] (unknown [10.163.33.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3A213FA4D; Wed, 9 Mar 2022 03:33:29 -0800 (PST) Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> Date: Wed, 9 Mar 2022 17:03:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Content-Language: en-US To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_033340_881436_76421664 X-CRM114-Status: GOOD ( 32.32 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org CgpPbiAzLzIvMjIgMTY6NDQsIEdlZXJ0IFV5dHRlcmhvZXZlbiB3cm90ZToKPiBIaSBBbnNodW1h biwKPiAKPiBPbiBXZWQsIE1hciAyLCAyMDIyIGF0IDEyOjA3IFBNIEFuc2h1bWFuIEtoYW5kdWFs Cj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+IHdyb3RlOgo+PiBPbiAzLzIvMjIgMzozNSBQ TSwgR2VlcnQgVXl0dGVyaG9ldmVuIHdyb3RlOgo+Pj4gT24gV2VkLCBNYXIgMiwgMjAyMiBhdCAx MDo1MSBBTSBBbnNodW1hbiBLaGFuZHVhbAo+Pj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+ IHdyb3RlOgo+Pj4+IE9uIDMvMi8yMiAxMjozNSBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToK Pj4+Pj4gTGUgMDIvMDMvMjAyMiDDoCAwNDoyMiwgQW5zaHVtYW4gS2hhbmR1YWwgYSDDqWNyaXQg Ogo+Pj4+Pj4gT24gMy8xLzIyIDE6NDYgUE0sIENocmlzdG9waGUgTGVyb3kgd3JvdGU6Cj4+Pj4+ Pj4gTGUgMDEvMDMvMjAyMiDDoCAwMTozMSwgUnVzc2VsbCBLaW5nIChPcmFjbGUpIGEgw6ljcml0 IDoKPj4+Pj4+Pj4gT24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5z aHVtYW4gS2hhbmR1YWwgd3JvdGU6Cj4+Pj4+Pj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3Nl bGwgS2luZyAoT3JhY2xlKSB3cm90ZToKPj4+Pj4+Pj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBh dCAwNDoxNzozMlBNICswNTMwLCBBbnNodW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4+Pj4+Pj4g VGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxhdGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dl dF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4+Pj4+Pj4gc3Vic2NyaWJpbmcgQVJDSF9IQVNfVk1fR0VU X1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFggYW5kIF9fUFhYWAo+Pj4+Pj4+Pj4+ PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdlciBuZWVkZWQuCj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3aHkg aGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+Pj4+Pj4+PiB3aGF0IHRoZSBwYWdl IHByb3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBh Cj4+Pj4+Pj4+Pj4gdGFibGUuCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBOb3Qgb25seSBpcyB0aGlz IG1vcmUgZXhwZW5zaXZlIGluIHRlcm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+ Pj4+Pj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNpemUgd2l0aCBpdC4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5lZml0IGlzLgo+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWluZyBfcnVu XyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+Pj4+Pj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4+Pj4+ Pj4gcGxhdGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhw b3J0ZWQgZm9yIGEgdGFibGUuCj4+Pj4+Pj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFu ZCBhcHBseWluZyBtb3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+Pj4+Pj4+PiBub3Qg bXVjaCBkaWZmZXJlbnQgdGhhbiBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJt cyBvZiBDUFUKPj4+Pj4+Pj4+IHVzYWdlLiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBp biB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBJIGRpc2FncmVlLgo+Pj4+ Pj4+Cj4+Pj4+Pj4gU28gZG8gSS4KPj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBIb3dldmVyLCBs ZXQncyBiYXNlIHRoaXMgZGlzYWdyZWVtZW50IG9uIHNvbWUgZXZpZGVuY2UuIEhlcmUgaXMgdGhl Cj4+Pj4+Pj4+IHByZXNlbnQgMzItYml0IEFSTSBpbXBsZW1lbnRhdGlvbjoKPj4+Pj4+Pj4KPj4+ Pj4+Pj4gMDAwMDAwNDggPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+PiAgICAgICAgIDQ4OiAg ICAgICBlMjAwMDAwZiAgICAgICAgYW5kICAgICByMCwgcjAsICMxNQo+Pj4+Pj4+PiAgICAgICAg IDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywgIzAKPj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICA0YzogUl9BUk1fTU9WV19BQlNfTkMgICAuTEFOQ0hPUjEKPj4+ Pj4+Pj4gICAgICAgICA1MDogICAgICAgZTM0MDMwMDAgICAgICAgIG1vdnQgICAgcjMsICMwCj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAg LkxBTkNIT1IxCj4+Pj4+Pj4+ICAgICAgICAgNTQ6ICAgICAgIGU3OTMwMTAwICAgICAgICBsZHIg ICAgIHIwLCBbcjMsIHIwLCBsc2wgIzJdCj4+Pj4+Pj4+ICAgICAgICAgNTg6ICAgICAgIGUxMmZm ZjFlICAgICAgICBieCAgICAgIGxyCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFRoYXQgaXMgZml2ZSBpbnN0 cnVjdGlvbnMgbG9uZy4KPj4+Pj4+Pgo+Pj4+Pj4+IE9uIHBwYzMyIEkgZ2V0Ogo+Pj4+Pj4+Cj4+ Pj4+Pj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+ICAgICAgICAgOTQ6IDNk IDIwIDAwIDAwICAgICBsaXMgICAgIHI5LDAKPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIDk2 OiBSX1BQQ19BRERSMTZfSEEgICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+Pj4+Pj4gICAgICAg ICA5ODogNTQgODQgMTYgYmEgICAgIHJsd2lubSAgcjQscjQsMiwyNiwyOQo+Pj4+Pj4+ICAgICAg ICAgOWM6IDM5IDI5IDAwIDAwICAgICBhZGRpICAgIHI5LHI5LDAKPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgIDllOiBSX1BQQ19BRERSMTZfTE8gICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+ Pj4+Pj4gICAgICAgICBhMDogN2QgMjkgMjAgMmUgICAgIGx3enggICAgcjkscjkscjQKPj4+Pj4+ PiAgICAgICAgIGE0OiA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAg ICAgICAgYTg6IDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+ Pj4+Pj4+IFBsZWFzZSBzaG93IHRoYXQgeW91ciBuZXcgaW1wbGVtZW50YXRpb24gaXMgbm90IG1v cmUgZXhwZW5zaXZlIG9uCj4+Pj4+Pj4+IDMyLWJpdCBBUk0uIFBsZWFzZSBkbyBzbyBieSBidWls ZGluZyBhIDMyLWJpdCBrZXJuZWwsIGFuZCBwcm92aWRpbmcKPj4+Pj4+Pj4gdGhlIGRpc2Fzc2Vt Ymx5Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gV2l0aCB5b3VyIHNlcmllcyBJIGdldDoKPj4+Pj4+Pgo+Pj4+ Pj4+IDAwMDAwMDAwIDx2bV9nZXRfcGFnZV9wcm90PjoKPj4+Pj4+PiAgICAgIDA6ICAgICAzZCAy MCAwMCAwMCAgICAgbGlzICAgICByOSwwCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAyOiBS X1BQQ19BRERSMTZfSEEgICAgICAucm9kYXRhCj4+Pj4+Pj4gICAgICA0OiAgICAgMzkgMjkgMDAg MDAgICAgIGFkZGkgICAgcjkscjksMAo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgNjogUl9Q UENfQUREUjE2X0xPICAgICAgLnJvZGF0YQo+Pj4+Pj4+ICAgICAgODogICAgIDU0IDg0IDE2IGJh ICAgICBybHdpbm0gIHI0LHI0LDIsMjYsMjkKPj4+Pj4+PiAgICAgIGM6ICAgICA3ZCA0OSAyMCAy ZSAgICAgbHd6eCAgICByMTAscjkscjQKPj4+Pj4+PiAgICAgMTA6ICAgICA3ZCA0YSA0YSAxNCAg ICAgYWRkICAgICByMTAscjEwLHI5Cj4+Pj4+Pj4gICAgIDE0OiAgICAgN2QgNDkgMDMgYTYgICAg IG10Y3RyICAgcjEwCj4+Pj4+Pj4gICAgIDE4OiAgICAgNGUgODAgMDQgMjAgICAgIGJjdHIKPj4+ Pj4+PiAgICAgMWM6ICAgICAzOSAyMCAwMyAxNSAgICAgbGkgICAgICByOSw3ODkKPj4+Pj4+PiAg ICAgMjA6ICAgICA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAy NDogICAgIDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+PiAgICAgMjg6ICAgICAzOSAyMCAwMSAx NSAgICAgbGkgICAgICByOSwyNzcKPj4+Pj4+PiAgICAgMmM6ICAgICA5MSAyMyAwMCAwMCAgICAg c3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAzMDogICAgIDRlIDgwIDAwIDIwICAgICBibHIK Pj4+Pj4+PiAgICAgMzQ6ICAgICAzOSAyMCAwNyAxNSAgICAgbGkgICAgICByOSwxODEzCj4+Pj4+ Pj4gICAgIDM4OiAgICAgOTEgMjMgMDAgMDAgICAgIHN0dyAgICAgcjksMChyMykKPj4+Pj4+PiAg ICAgM2M6ICAgICA0ZSA4MCAwMCAyMCAgICAgYmxyCj4+Pj4+Pj4gICAgIDQwOiAgICAgMzkgMjAg MDUgMTUgICAgIGxpICAgICAgcjksMTMwMQo+Pj4+Pj4+ICAgICA0NDogICAgIDkxIDIzIDAwIDAw ICAgICBzdHcgICAgIHI5LDAocjMpCj4+Pj4+Pj4gICAgIDQ4OiAgICAgNGUgODAgMDAgMjAgICAg IGJscgo+Pj4+Pj4+ICAgICA0YzogICAgIDM5IDIwIDAxIDExICAgICBsaSAgICAgIHI5LDI3Mwo+ Pj4+Pj4+ICAgICA1MDogICAgIDRiIGZmIGZmIGQwICAgICBiICAgICAgIDIwIDx2bV9nZXRfcGFn ZV9wcm90KzB4MjA+Cj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoYXQgaXMgZGVmaW5pdGVseSBt b3JlIGV4cGVuc2l2ZSwgaXQgaW1wbGVtZW50cyBhIHRhYmxlIG9mIGJyYW5jaGVzLgo+Pj4+Pj4K Pj4+Pj4+IE9rYXksIHdpbGwgc3BsaXQgb3V0IHRoZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0 IHJldGFpbnMgZXhpc3RpbmcKPj4+Pj4+IHRhYmxlIGxvb2sgdXAgbWV0aG9kLiBBbHNvIHBsYW5u aW5nIHRvIGtlZXAgdGhhdCBpbnNpZGUgc2FtZSBmaWxlCj4+Pj4+PiAoYXJjaC9wb3dlcnBjL21t L21tYXAuYyksIHVubGVzcyB5b3UgaGF2ZSBhIGRpZmZlcmVuY2UgcHJlZmVyZW5jZS4KPj4+Pj4K Pj4+Pj4gTXkgcG9pbnQgd2FzIG5vdCB0byBnZXQgc29tZXRoaW5nIHNwZWNpZmljIGZvciBQUEMz MiwgYnV0IHRvIGFtcGxpZnkgb24KPj4+Pj4gUnVzc2VsbCdzIG9iamVjdGlvbi4KPj4+Pj4KPj4+ Pj4gQXMgdGhpcyBpcyBiYWQgZm9yIEFSTSBhbmQgYmFkIGZvciBQUEMzMiwgZG8gd2UgaGF2ZSBh bnkgZXZpZGVuY2UgdGhhdAo+Pj4+PiB5b3VyIGNoYW5nZSBpcyBnb29kIGZvciBhbnkgb3RoZXIg YXJjaGl0ZWN0dXJlID8KPj4+Pj4KPj4+Pj4gSSBjaGVja2VkIFBQQzY0IGFuZCB0aGVyZSBpcyBl eGFjdGx5IHRoZSBzYW1lIGRyYXdiYWNrLiBXaXRoIHRoZSBjdXJyZW50Cj4+Pj4+IGltcGxlbWVu dGF0aW9uIGl0IGlzIGEgc21hbGwgZnVuY3Rpb24gcGVyZm9ybWluZyB0YWJsZSByZWFkIHRoZW4g YSBmZXcKPj4+Pj4gYWRqdXN0bWVudC4gQWZ0ZXIgeW91ciBjaGFuZ2UgaXQgaXMgYSBiaWdnZXIg ZnVuY3Rpb24gaW1wbGVtZW50aW5nIGEKPj4+Pj4gdGFibGUgb2YgYnJhbmNoZXMuCj4+Pj4KPj4+ PiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHdvdWxkIG5vdCBiZSB0aGUgY2FzZSBmb3IgYW55IG90 aGVyIHN3aXRjaCBjYXNlCj4+Pj4gc3RhdGVtZW50IG9uIHRoZSBwbGF0Zm9ybSA/IElzIHRoZXJl IHNvbWV0aGluZyBzcGVjaWZpYy9kaWZmZXJlbnQganVzdAo+Pj4+IG9uIHZtX2dldF9wYWdlX3By b3QoKSBpbXBsZW1lbnRhdGlvbiA/IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHN3aXRjaAo+Pj4+ IGNhc2Ugc3RhdGVtZW50cyBzaG91bGQganVzdCBiZSBhdm9pZGVkIGluc3RlYWQgPwo+Pj4+Cj4+ Pj4+Cj4+Pj4+IFNvLCBhcyByZXF1ZXN0ZWQgYnkgUnVzc2VsbCwgY291bGQgeW91IGxvb2sgYXQg dGhlIGRpc2Fzc2VtYmx5IGZvciBvdGhlcgo+Pj4+PiBhcmNoaXRlY3R1cmVzIGFuZCBzaG93IHVz IHRoYXQgQVJNIGFuZCBQT1dFUlBDIGFyZSB0aGUgb25seSBvbmVzIGZvcgo+Pj4+PiB3aGljaCB5 b3VyIGNoYW5nZSBpcyBub3Qgb3B0aW1hbCA/Cj4+Pj4KPj4+PiBCdXQgdGhlIHByaW1hcnkgcHVy cG9zZSBvZiB0aGlzIHNlcmllcyBpcyBub3QgdG8gZ3VhcmFudGVlIG9wdGltaXplZAo+Pj4+IGNv ZGUgb24gcGxhdGZvcm0gYnkgcGxhdGZvcm0gYmFzaXMsIHdoaWxlIG1pZ3JhdGluZyBmcm9tIGEg dGFibGUgYmFzZWQKPj4+PiBsb29rIHVwIG1ldGhvZCBpbnRvIGEgc3dpdGNoIGNhc2Ugc3RhdGVt ZW50Lgo+Pj4+Cj4+Pj4gQnV0IGluc3RlYWQsIHRoZSBwdXJwb3NlcyBpcyB0byByZW1vdmUgY3Vy cmVudCBsZXZlbHMgb2YgdW5uZWNlc3NhcnkKPj4+PiBhYnN0cmFjdGlvbiB3aGlsZSBjb252ZXJ0 aW5nIGEgdm1fZmxhZ3MgYWNjZXNzIGNvbWJpbmF0aW9uIGludG8gcGFnZQo+Pj4+IHByb3RlY3Rp b24uIFRoZSBzd2l0Y2ggY2FzZSBzdGF0ZW1lbnQgZm9yIHBsYXRmb3JtIGltcGxlbWVudGF0aW9u IG9mCj4+Pj4gdm1fZ2V0X3BhZ2VfcHJvdCgpIGp1c3Qgc2VlbWVkIGxvZ2ljYWwgZW5vdWdoLiBD aHJpc3RvcGgncyBvcmlnaW5hbAo+Pj4+IHN1Z2dlc3Rpb24gcGF0Y2ggZm9yIHg4NiBoYWQgdGhl IHNhbWUgaW1wbGVtZW50YXRpb24gYXMgd2VsbC4KPj4+Pgo+Pj4+IEJ1dCBpZiB0aGUgdGFibGUg bG9vayB1cCBpcyBzdGlsbCBiZXR0ZXIvcHJlZmVycmVkIG1ldGhvZCBvbiBjZXJ0YWluCj4+Pj4g cGxhdGZvcm1zIGxpa2UgYXJtIG9yIHBwYzMyLCB3aWxsIGJlIGhhcHB5IHRvIHByZXNlcnZlIHRo YXQuCj4+Pgo+Pj4gSSBkb3VidCB0aGUgc3dpdGNoKCkgdmFyaWFudCB3b3VsZCBnaXZlIGJldHRl ciBjb2RlIG9uIGFueSBwbGF0Zm9ybS4KPj4+Cj4+PiBXaGF0IGFib3V0IHVzaW5nIHRhYmxlcyBl dmVyeXdoZXJlLCB1c2luZyBkZXNpZ25hdGVkIGluaXRpYWxpemVycwo+Pj4gdG8gaW1wcm92ZSBy ZWFkYWJpbGl0eT8KPj4KPj4gRGVzaWduYXRlZCBpbml0aWFsaXplcnMgPyBDb3VsZCB5b3UgcGxl YXNlIGJlIG1vcmUgc3BlY2lmaWMuIEEgdGFibGUgbG9vawo+PiB1cCBvbiBhcm0gcGxhdGZvcm0g d291bGQgYmUgc29tZXRoaW5nIGxpa2UgdGhpcyBhbmQgYXJtX3Byb3RlY3Rpb25fbWFwW10KPj4g bmVlZHMgdG8gYmUgdXBkYXRlZCB3aXRoIHVzZXJfcGdwcm90IGxpa2UgYmVmb3JlLiBKdXN0IHdv bmRlcmluZyBob3cgYQo+PiBkZXNpZ25hdGVkIGluaXRpYWxpemVyIHdpbGwgaGVscCBoZXJlLgo+ IAo+IEl0J3MgbW9yZSByZWFkYWJsZSB0aGFuIHRoZSBvcmlnaW5hbDoKPiAKPiAgICAgcGdwcm90 X3QgcHJvdGVjdGlvbl9tYXBbMTZdIF9fcm9fYWZ0ZXJfaW5pdCA9IHsKPiAgICAgICAgICAgICBf X1AwMDAsIF9fUDAwMSwgX19QMDEwLCBfX1AwMTEsIF9fUDEwMCwgX19QMTAxLCBfX1AxMTAsIF9f UDExMSwKPiAgICAgICAgICAgICBfX1MwMDAsIF9fUzAwMSwgX19TMDEwLCBfX1MwMTEsIF9fUzEw MCwgX19TMTAxLCBfX1MxMTAsIF9fUzExMQo+ICAgICB9Owo+IAo+Pgo+PiBzdGF0aWMgcGdwcm90 X3QgYXJtX3Byb3RlY3Rpb25fbWFwWzE2XSBfX3JvX2FmdGVyX2luaXQgPSB7Cj4+ICAgICAgICBb Vk1fTk9ORV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9O T05FLAo+PiAgICAgICAgW1ZNX1JFQURdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPSBfX1BBR0VfUkVBRE9OTFksCj4+ICAgICAgICBbVk1fV1JJVEVdICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9DT1BZLAo+PiAgICAgICAgW1ZNX1dS SVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWSwK Pj4gICAgICAgIFtWTV9FWEVDXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1fRVhFQyB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9SRUFET05MWV9FWEVDLAo+PiAgICAg ICAgW1ZNX0VYRUMgfCBWTV9XUklURV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX0VYRUMgfCBWTV9XUklURSB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX1NIQVJFRF0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfTk9ORSwKPj4gICAg ICAgIFtWTV9TSEFSRUQgfCBWTV9SRUFEXSAgICAgICAgICAgICAgICAgICAgICAgICAgID0gX19Q QUdFX1JFQURPTkxZLAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZNX1dSSVRFXSAgICAgICAgICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZN X1dSSVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAg ICAgW1ZNX1NIQVJFRCB8IFZNX0VYRUNdICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfUkVBRE9OTFlfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fUkVB RF0gICAgICAgICAgICAgICAgID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1f U0hBUkVEIHwgVk1fRVhFQyB8IFZNX1dSSVRFXSAgICAgICAgICAgICAgICA9IF9fUEFHRV9TSEFS RURfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fV1JJVEUgfCBWTV9S RUFEXSAgICAgID0gX19QQUdFX1NIQVJFRF9FWEVDCj4+IH07Cj4gCj4gWWVhaCwgbGlrZSB0aGF0 Lgo+IAo+IFNlZW1zIGxpa2UgeW91IGFscmVhZHkgbWFkZSBzdWNoIGEgY29udmVyc2lvbiBpbgo+ IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC8xNjQ1NDI1NTE5LTkwMzQtMy1naXQtc2VuZC1l bWFpbC1hbnNodW1hbi5raGFuZHVhbEBhcm0uY29tLwoKV2lsbCByZXdvcmsgdGhlIHNlcmllcyBp biB0d28gZGlmZmVyZW50IHBoYXNlcyBhcyBtZW50aW9uZWQgb24gdGhlIG90aGVyIHRocmVhZC4K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXNu cHMtYXJjIG1haWxpbmcgbGlzdApsaW51eC1zbnBzLWFyY0BsaXN0cy5pbmZyYWRlYWQub3JnCmh0 dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtc25wcy1hcmMK 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 3C7F4C433EF for ; Wed, 9 Mar 2022 11:34:04 +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=3471xHgP7nM4+CJtTpM5sRGUM8RwH+uy8InLH2tiVnA=; b=lXdwcraGvS/9LY WPdtZ48TMiZSSTyew6vx+fplHbu0QUpwee1i1WN3htkDrKd26cHaSLHZ8HtCmQ/+IwGX62M2G0lNx W+BrjTR+JlV9kujCjWiEhMQrsnHDs8Oxn2IvAAXT+wMp0Q5i7VbEEVLxigcCJGxv4JIJDjf5ZW9Ih EPsBBYeK9Mu52BO8z8SRbaP5EEGNX/+PMhZLD9i9oj/TtFkpbn0x45IBGuipnksKWreUEbz4qADPd 4pXd7sEHPa/merrc4IY2mmQucacjX1tVO+WyT0qKphOZaq54IYszEQa8XaArTjaGXDA5pDjf0iV8g /Iu7pS/VSfaJv560kRKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZo-008Is8-Gp; Wed, 09 Mar 2022 11:33:56 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZY-008Inh-NB; Wed, 09 Mar 2022 11:33:42 +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 C45AC1655; Wed, 9 Mar 2022 03:33:39 -0800 (PST) Received: from [10.163.33.203] (unknown [10.163.33.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3A213FA4D; Wed, 9 Mar 2022 03:33:29 -0800 (PST) Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> Date: Wed, 9 Mar 2022 17:03:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Content-Language: en-US To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_033340_881436_76421664 X-CRM114-Status: GOOD ( 32.32 ) X-BeenThere: linux-riscv@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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org CgpPbiAzLzIvMjIgMTY6NDQsIEdlZXJ0IFV5dHRlcmhvZXZlbiB3cm90ZToKPiBIaSBBbnNodW1h biwKPiAKPiBPbiBXZWQsIE1hciAyLCAyMDIyIGF0IDEyOjA3IFBNIEFuc2h1bWFuIEtoYW5kdWFs Cj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+IHdyb3RlOgo+PiBPbiAzLzIvMjIgMzozNSBQ TSwgR2VlcnQgVXl0dGVyaG9ldmVuIHdyb3RlOgo+Pj4gT24gV2VkLCBNYXIgMiwgMjAyMiBhdCAx MDo1MSBBTSBBbnNodW1hbiBLaGFuZHVhbAo+Pj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+ IHdyb3RlOgo+Pj4+IE9uIDMvMi8yMiAxMjozNSBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToK Pj4+Pj4gTGUgMDIvMDMvMjAyMiDDoCAwNDoyMiwgQW5zaHVtYW4gS2hhbmR1YWwgYSDDqWNyaXQg Ogo+Pj4+Pj4gT24gMy8xLzIyIDE6NDYgUE0sIENocmlzdG9waGUgTGVyb3kgd3JvdGU6Cj4+Pj4+ Pj4gTGUgMDEvMDMvMjAyMiDDoCAwMTozMSwgUnVzc2VsbCBLaW5nIChPcmFjbGUpIGEgw6ljcml0 IDoKPj4+Pj4+Pj4gT24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5z aHVtYW4gS2hhbmR1YWwgd3JvdGU6Cj4+Pj4+Pj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3Nl bGwgS2luZyAoT3JhY2xlKSB3cm90ZToKPj4+Pj4+Pj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBh dCAwNDoxNzozMlBNICswNTMwLCBBbnNodW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4+Pj4+Pj4g VGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxhdGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dl dF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4+Pj4+Pj4gc3Vic2NyaWJpbmcgQVJDSF9IQVNfVk1fR0VU X1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFggYW5kIF9fUFhYWAo+Pj4+Pj4+Pj4+ PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdlciBuZWVkZWQuCj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3aHkg aGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+Pj4+Pj4+PiB3aGF0IHRoZSBwYWdl IHByb3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBh Cj4+Pj4+Pj4+Pj4gdGFibGUuCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBOb3Qgb25seSBpcyB0aGlz IG1vcmUgZXhwZW5zaXZlIGluIHRlcm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+ Pj4+Pj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNpemUgd2l0aCBpdC4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5lZml0IGlzLgo+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWluZyBfcnVu XyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+Pj4+Pj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4+Pj4+ Pj4gcGxhdGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhw b3J0ZWQgZm9yIGEgdGFibGUuCj4+Pj4+Pj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFu ZCBhcHBseWluZyBtb3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+Pj4+Pj4+PiBub3Qg bXVjaCBkaWZmZXJlbnQgdGhhbiBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJt cyBvZiBDUFUKPj4+Pj4+Pj4+IHVzYWdlLiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBp biB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBJIGRpc2FncmVlLgo+Pj4+ Pj4+Cj4+Pj4+Pj4gU28gZG8gSS4KPj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBIb3dldmVyLCBs ZXQncyBiYXNlIHRoaXMgZGlzYWdyZWVtZW50IG9uIHNvbWUgZXZpZGVuY2UuIEhlcmUgaXMgdGhl Cj4+Pj4+Pj4+IHByZXNlbnQgMzItYml0IEFSTSBpbXBsZW1lbnRhdGlvbjoKPj4+Pj4+Pj4KPj4+ Pj4+Pj4gMDAwMDAwNDggPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+PiAgICAgICAgIDQ4OiAg ICAgICBlMjAwMDAwZiAgICAgICAgYW5kICAgICByMCwgcjAsICMxNQo+Pj4+Pj4+PiAgICAgICAg IDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywgIzAKPj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICA0YzogUl9BUk1fTU9WV19BQlNfTkMgICAuTEFOQ0hPUjEKPj4+ Pj4+Pj4gICAgICAgICA1MDogICAgICAgZTM0MDMwMDAgICAgICAgIG1vdnQgICAgcjMsICMwCj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAg LkxBTkNIT1IxCj4+Pj4+Pj4+ICAgICAgICAgNTQ6ICAgICAgIGU3OTMwMTAwICAgICAgICBsZHIg ICAgIHIwLCBbcjMsIHIwLCBsc2wgIzJdCj4+Pj4+Pj4+ICAgICAgICAgNTg6ICAgICAgIGUxMmZm ZjFlICAgICAgICBieCAgICAgIGxyCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFRoYXQgaXMgZml2ZSBpbnN0 cnVjdGlvbnMgbG9uZy4KPj4+Pj4+Pgo+Pj4+Pj4+IE9uIHBwYzMyIEkgZ2V0Ogo+Pj4+Pj4+Cj4+ Pj4+Pj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+ICAgICAgICAgOTQ6IDNk IDIwIDAwIDAwICAgICBsaXMgICAgIHI5LDAKPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIDk2 OiBSX1BQQ19BRERSMTZfSEEgICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+Pj4+Pj4gICAgICAg ICA5ODogNTQgODQgMTYgYmEgICAgIHJsd2lubSAgcjQscjQsMiwyNiwyOQo+Pj4+Pj4+ICAgICAg ICAgOWM6IDM5IDI5IDAwIDAwICAgICBhZGRpICAgIHI5LHI5LDAKPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgIDllOiBSX1BQQ19BRERSMTZfTE8gICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+ Pj4+Pj4gICAgICAgICBhMDogN2QgMjkgMjAgMmUgICAgIGx3enggICAgcjkscjkscjQKPj4+Pj4+ PiAgICAgICAgIGE0OiA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAg ICAgICAgYTg6IDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+ Pj4+Pj4+IFBsZWFzZSBzaG93IHRoYXQgeW91ciBuZXcgaW1wbGVtZW50YXRpb24gaXMgbm90IG1v cmUgZXhwZW5zaXZlIG9uCj4+Pj4+Pj4+IDMyLWJpdCBBUk0uIFBsZWFzZSBkbyBzbyBieSBidWls ZGluZyBhIDMyLWJpdCBrZXJuZWwsIGFuZCBwcm92aWRpbmcKPj4+Pj4+Pj4gdGhlIGRpc2Fzc2Vt Ymx5Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gV2l0aCB5b3VyIHNlcmllcyBJIGdldDoKPj4+Pj4+Pgo+Pj4+ Pj4+IDAwMDAwMDAwIDx2bV9nZXRfcGFnZV9wcm90PjoKPj4+Pj4+PiAgICAgIDA6ICAgICAzZCAy MCAwMCAwMCAgICAgbGlzICAgICByOSwwCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAyOiBS X1BQQ19BRERSMTZfSEEgICAgICAucm9kYXRhCj4+Pj4+Pj4gICAgICA0OiAgICAgMzkgMjkgMDAg MDAgICAgIGFkZGkgICAgcjkscjksMAo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgNjogUl9Q UENfQUREUjE2X0xPICAgICAgLnJvZGF0YQo+Pj4+Pj4+ICAgICAgODogICAgIDU0IDg0IDE2IGJh ICAgICBybHdpbm0gIHI0LHI0LDIsMjYsMjkKPj4+Pj4+PiAgICAgIGM6ICAgICA3ZCA0OSAyMCAy ZSAgICAgbHd6eCAgICByMTAscjkscjQKPj4+Pj4+PiAgICAgMTA6ICAgICA3ZCA0YSA0YSAxNCAg ICAgYWRkICAgICByMTAscjEwLHI5Cj4+Pj4+Pj4gICAgIDE0OiAgICAgN2QgNDkgMDMgYTYgICAg IG10Y3RyICAgcjEwCj4+Pj4+Pj4gICAgIDE4OiAgICAgNGUgODAgMDQgMjAgICAgIGJjdHIKPj4+ Pj4+PiAgICAgMWM6ICAgICAzOSAyMCAwMyAxNSAgICAgbGkgICAgICByOSw3ODkKPj4+Pj4+PiAg ICAgMjA6ICAgICA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAy NDogICAgIDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+PiAgICAgMjg6ICAgICAzOSAyMCAwMSAx NSAgICAgbGkgICAgICByOSwyNzcKPj4+Pj4+PiAgICAgMmM6ICAgICA5MSAyMyAwMCAwMCAgICAg c3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAzMDogICAgIDRlIDgwIDAwIDIwICAgICBibHIK Pj4+Pj4+PiAgICAgMzQ6ICAgICAzOSAyMCAwNyAxNSAgICAgbGkgICAgICByOSwxODEzCj4+Pj4+ Pj4gICAgIDM4OiAgICAgOTEgMjMgMDAgMDAgICAgIHN0dyAgICAgcjksMChyMykKPj4+Pj4+PiAg ICAgM2M6ICAgICA0ZSA4MCAwMCAyMCAgICAgYmxyCj4+Pj4+Pj4gICAgIDQwOiAgICAgMzkgMjAg MDUgMTUgICAgIGxpICAgICAgcjksMTMwMQo+Pj4+Pj4+ICAgICA0NDogICAgIDkxIDIzIDAwIDAw ICAgICBzdHcgICAgIHI5LDAocjMpCj4+Pj4+Pj4gICAgIDQ4OiAgICAgNGUgODAgMDAgMjAgICAg IGJscgo+Pj4+Pj4+ICAgICA0YzogICAgIDM5IDIwIDAxIDExICAgICBsaSAgICAgIHI5LDI3Mwo+ Pj4+Pj4+ICAgICA1MDogICAgIDRiIGZmIGZmIGQwICAgICBiICAgICAgIDIwIDx2bV9nZXRfcGFn ZV9wcm90KzB4MjA+Cj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoYXQgaXMgZGVmaW5pdGVseSBt b3JlIGV4cGVuc2l2ZSwgaXQgaW1wbGVtZW50cyBhIHRhYmxlIG9mIGJyYW5jaGVzLgo+Pj4+Pj4K Pj4+Pj4+IE9rYXksIHdpbGwgc3BsaXQgb3V0IHRoZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0 IHJldGFpbnMgZXhpc3RpbmcKPj4+Pj4+IHRhYmxlIGxvb2sgdXAgbWV0aG9kLiBBbHNvIHBsYW5u aW5nIHRvIGtlZXAgdGhhdCBpbnNpZGUgc2FtZSBmaWxlCj4+Pj4+PiAoYXJjaC9wb3dlcnBjL21t L21tYXAuYyksIHVubGVzcyB5b3UgaGF2ZSBhIGRpZmZlcmVuY2UgcHJlZmVyZW5jZS4KPj4+Pj4K Pj4+Pj4gTXkgcG9pbnQgd2FzIG5vdCB0byBnZXQgc29tZXRoaW5nIHNwZWNpZmljIGZvciBQUEMz MiwgYnV0IHRvIGFtcGxpZnkgb24KPj4+Pj4gUnVzc2VsbCdzIG9iamVjdGlvbi4KPj4+Pj4KPj4+ Pj4gQXMgdGhpcyBpcyBiYWQgZm9yIEFSTSBhbmQgYmFkIGZvciBQUEMzMiwgZG8gd2UgaGF2ZSBh bnkgZXZpZGVuY2UgdGhhdAo+Pj4+PiB5b3VyIGNoYW5nZSBpcyBnb29kIGZvciBhbnkgb3RoZXIg YXJjaGl0ZWN0dXJlID8KPj4+Pj4KPj4+Pj4gSSBjaGVja2VkIFBQQzY0IGFuZCB0aGVyZSBpcyBl eGFjdGx5IHRoZSBzYW1lIGRyYXdiYWNrLiBXaXRoIHRoZSBjdXJyZW50Cj4+Pj4+IGltcGxlbWVu dGF0aW9uIGl0IGlzIGEgc21hbGwgZnVuY3Rpb24gcGVyZm9ybWluZyB0YWJsZSByZWFkIHRoZW4g YSBmZXcKPj4+Pj4gYWRqdXN0bWVudC4gQWZ0ZXIgeW91ciBjaGFuZ2UgaXQgaXMgYSBiaWdnZXIg ZnVuY3Rpb24gaW1wbGVtZW50aW5nIGEKPj4+Pj4gdGFibGUgb2YgYnJhbmNoZXMuCj4+Pj4KPj4+ PiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHdvdWxkIG5vdCBiZSB0aGUgY2FzZSBmb3IgYW55IG90 aGVyIHN3aXRjaCBjYXNlCj4+Pj4gc3RhdGVtZW50IG9uIHRoZSBwbGF0Zm9ybSA/IElzIHRoZXJl IHNvbWV0aGluZyBzcGVjaWZpYy9kaWZmZXJlbnQganVzdAo+Pj4+IG9uIHZtX2dldF9wYWdlX3By b3QoKSBpbXBsZW1lbnRhdGlvbiA/IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHN3aXRjaAo+Pj4+ IGNhc2Ugc3RhdGVtZW50cyBzaG91bGQganVzdCBiZSBhdm9pZGVkIGluc3RlYWQgPwo+Pj4+Cj4+ Pj4+Cj4+Pj4+IFNvLCBhcyByZXF1ZXN0ZWQgYnkgUnVzc2VsbCwgY291bGQgeW91IGxvb2sgYXQg dGhlIGRpc2Fzc2VtYmx5IGZvciBvdGhlcgo+Pj4+PiBhcmNoaXRlY3R1cmVzIGFuZCBzaG93IHVz IHRoYXQgQVJNIGFuZCBQT1dFUlBDIGFyZSB0aGUgb25seSBvbmVzIGZvcgo+Pj4+PiB3aGljaCB5 b3VyIGNoYW5nZSBpcyBub3Qgb3B0aW1hbCA/Cj4+Pj4KPj4+PiBCdXQgdGhlIHByaW1hcnkgcHVy cG9zZSBvZiB0aGlzIHNlcmllcyBpcyBub3QgdG8gZ3VhcmFudGVlIG9wdGltaXplZAo+Pj4+IGNv ZGUgb24gcGxhdGZvcm0gYnkgcGxhdGZvcm0gYmFzaXMsIHdoaWxlIG1pZ3JhdGluZyBmcm9tIGEg dGFibGUgYmFzZWQKPj4+PiBsb29rIHVwIG1ldGhvZCBpbnRvIGEgc3dpdGNoIGNhc2Ugc3RhdGVt ZW50Lgo+Pj4+Cj4+Pj4gQnV0IGluc3RlYWQsIHRoZSBwdXJwb3NlcyBpcyB0byByZW1vdmUgY3Vy cmVudCBsZXZlbHMgb2YgdW5uZWNlc3NhcnkKPj4+PiBhYnN0cmFjdGlvbiB3aGlsZSBjb252ZXJ0 aW5nIGEgdm1fZmxhZ3MgYWNjZXNzIGNvbWJpbmF0aW9uIGludG8gcGFnZQo+Pj4+IHByb3RlY3Rp b24uIFRoZSBzd2l0Y2ggY2FzZSBzdGF0ZW1lbnQgZm9yIHBsYXRmb3JtIGltcGxlbWVudGF0aW9u IG9mCj4+Pj4gdm1fZ2V0X3BhZ2VfcHJvdCgpIGp1c3Qgc2VlbWVkIGxvZ2ljYWwgZW5vdWdoLiBD aHJpc3RvcGgncyBvcmlnaW5hbAo+Pj4+IHN1Z2dlc3Rpb24gcGF0Y2ggZm9yIHg4NiBoYWQgdGhl IHNhbWUgaW1wbGVtZW50YXRpb24gYXMgd2VsbC4KPj4+Pgo+Pj4+IEJ1dCBpZiB0aGUgdGFibGUg bG9vayB1cCBpcyBzdGlsbCBiZXR0ZXIvcHJlZmVycmVkIG1ldGhvZCBvbiBjZXJ0YWluCj4+Pj4g cGxhdGZvcm1zIGxpa2UgYXJtIG9yIHBwYzMyLCB3aWxsIGJlIGhhcHB5IHRvIHByZXNlcnZlIHRo YXQuCj4+Pgo+Pj4gSSBkb3VidCB0aGUgc3dpdGNoKCkgdmFyaWFudCB3b3VsZCBnaXZlIGJldHRl ciBjb2RlIG9uIGFueSBwbGF0Zm9ybS4KPj4+Cj4+PiBXaGF0IGFib3V0IHVzaW5nIHRhYmxlcyBl dmVyeXdoZXJlLCB1c2luZyBkZXNpZ25hdGVkIGluaXRpYWxpemVycwo+Pj4gdG8gaW1wcm92ZSBy ZWFkYWJpbGl0eT8KPj4KPj4gRGVzaWduYXRlZCBpbml0aWFsaXplcnMgPyBDb3VsZCB5b3UgcGxl YXNlIGJlIG1vcmUgc3BlY2lmaWMuIEEgdGFibGUgbG9vawo+PiB1cCBvbiBhcm0gcGxhdGZvcm0g d291bGQgYmUgc29tZXRoaW5nIGxpa2UgdGhpcyBhbmQgYXJtX3Byb3RlY3Rpb25fbWFwW10KPj4g bmVlZHMgdG8gYmUgdXBkYXRlZCB3aXRoIHVzZXJfcGdwcm90IGxpa2UgYmVmb3JlLiBKdXN0IHdv bmRlcmluZyBob3cgYQo+PiBkZXNpZ25hdGVkIGluaXRpYWxpemVyIHdpbGwgaGVscCBoZXJlLgo+ IAo+IEl0J3MgbW9yZSByZWFkYWJsZSB0aGFuIHRoZSBvcmlnaW5hbDoKPiAKPiAgICAgcGdwcm90 X3QgcHJvdGVjdGlvbl9tYXBbMTZdIF9fcm9fYWZ0ZXJfaW5pdCA9IHsKPiAgICAgICAgICAgICBf X1AwMDAsIF9fUDAwMSwgX19QMDEwLCBfX1AwMTEsIF9fUDEwMCwgX19QMTAxLCBfX1AxMTAsIF9f UDExMSwKPiAgICAgICAgICAgICBfX1MwMDAsIF9fUzAwMSwgX19TMDEwLCBfX1MwMTEsIF9fUzEw MCwgX19TMTAxLCBfX1MxMTAsIF9fUzExMQo+ICAgICB9Owo+IAo+Pgo+PiBzdGF0aWMgcGdwcm90 X3QgYXJtX3Byb3RlY3Rpb25fbWFwWzE2XSBfX3JvX2FmdGVyX2luaXQgPSB7Cj4+ICAgICAgICBb Vk1fTk9ORV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9O T05FLAo+PiAgICAgICAgW1ZNX1JFQURdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPSBfX1BBR0VfUkVBRE9OTFksCj4+ICAgICAgICBbVk1fV1JJVEVdICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9DT1BZLAo+PiAgICAgICAgW1ZNX1dS SVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWSwK Pj4gICAgICAgIFtWTV9FWEVDXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1fRVhFQyB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9SRUFET05MWV9FWEVDLAo+PiAgICAg ICAgW1ZNX0VYRUMgfCBWTV9XUklURV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX0VYRUMgfCBWTV9XUklURSB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX1NIQVJFRF0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfTk9ORSwKPj4gICAg ICAgIFtWTV9TSEFSRUQgfCBWTV9SRUFEXSAgICAgICAgICAgICAgICAgICAgICAgICAgID0gX19Q QUdFX1JFQURPTkxZLAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZNX1dSSVRFXSAgICAgICAgICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZN X1dSSVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAg ICAgW1ZNX1NIQVJFRCB8IFZNX0VYRUNdICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfUkVBRE9OTFlfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fUkVB RF0gICAgICAgICAgICAgICAgID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1f U0hBUkVEIHwgVk1fRVhFQyB8IFZNX1dSSVRFXSAgICAgICAgICAgICAgICA9IF9fUEFHRV9TSEFS RURfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fV1JJVEUgfCBWTV9S RUFEXSAgICAgID0gX19QQUdFX1NIQVJFRF9FWEVDCj4+IH07Cj4gCj4gWWVhaCwgbGlrZSB0aGF0 Lgo+IAo+IFNlZW1zIGxpa2UgeW91IGFscmVhZHkgbWFkZSBzdWNoIGEgY29udmVyc2lvbiBpbgo+ IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC8xNjQ1NDI1NTE5LTkwMzQtMy1naXQtc2VuZC1l bWFpbC1hbnNodW1hbi5raGFuZHVhbEBhcm0uY29tLwoKV2lsbCByZXdvcmsgdGhlIHNlcmllcyBp biB0d28gZGlmZmVyZW50IHBoYXNlcyBhcyBtZW50aW9uZWQgb24gdGhlIG90aGVyIHRocmVhZC4K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LXJp c2N2IG1haWxpbmcgbGlzdApsaW51eC1yaXNjdkBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9s aXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtcmlzY3YK 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 72D0EC433F5 for ; Wed, 9 Mar 2022 11:34:39 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KD98X6N0xz3bns for ; Wed, 9 Mar 2022 22:34:36 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arm.com (client-ip=217.140.110.172; helo=foss.arm.com; envelope-from=anshuman.khandual@arm.com; receiver=) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lists.ozlabs.org (Postfix) with ESMTP id 4KD9830yrPz30Fn for ; Wed, 9 Mar 2022 22:34:10 +1100 (AEDT) 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 C45AC1655; Wed, 9 Mar 2022 03:33:39 -0800 (PST) Received: from [10.163.33.203] (unknown [10.163.33.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3A213FA4D; Wed, 9 Mar 2022 03:33:29 -0800 (PST) Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> Date: Wed, 9 Mar 2022 17:03:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Content-Language: en-US To: Geert Uytterhoeven References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 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" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-csky@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "Russell King \(Oracle\)" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 3/2/22 16:44, Geert Uytterhoeven wrote: > Hi Anshuman, > > On Wed, Mar 2, 2022 at 12:07 PM Anshuman Khandual > wrote: >> On 3/2/22 3:35 PM, Geert Uytterhoeven wrote: >>> On Wed, Mar 2, 2022 at 10:51 AM Anshuman Khandual >>> wrote: >>>> On 3/2/22 12:35 PM, Christophe Leroy wrote: >>>>> Le 02/03/2022 à 04:22, Anshuman Khandual a écrit : >>>>>> On 3/1/22 1:46 PM, Christophe Leroy wrote: >>>>>>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >>>>>>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>>>>>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>>>>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>>>>>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>>>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>>>>>>>> macros can be dropped which are no longer needed. >>>>>>>>>> >>>>>>>>>> What I would really like to know is why having to run _code_ to work out >>>>>>>>>> what the page protections need to be is better than looking it up in a >>>>>>>>>> table. >>>>>>>>>> >>>>>>>>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>>>>>>>> additional code size with it. >>>>>>>>>> >>>>>>>>>> I'm struggling to see what the benefit is. >>>>>>>>> >>>>>>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>>>>>>>> protection values. Although that is being run in the core MM and from a >>>>>>>>> platform perspective __SXXX, __PXXX are just being exported for a table. >>>>>>>>> Looking it up in a table (and applying more constructs there after) is >>>>>>>>> not much different than a clean switch case statement in terms of CPU >>>>>>>>> usage. So this is not more expensive in terms of CPU cycles. >>>>>>>> >>>>>>>> I disagree. >>>>>>> >>>>>>> So do I. >>>>>>> >>>>>>>> >>>>>>>> However, let's base this disagreement on some evidence. Here is the >>>>>>>> present 32-bit ARM implementation: >>>>>>>> >>>>>>>> 00000048 : >>>>>>>> 48: e200000f and r0, r0, #15 >>>>>>>> 4c: e3003000 movw r3, #0 >>>>>>>> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >>>>>>>> 50: e3403000 movt r3, #0 >>>>>>>> 50: R_ARM_MOVT_ABS .LANCHOR1 >>>>>>>> 54: e7930100 ldr r0, [r3, r0, lsl #2] >>>>>>>> 58: e12fff1e bx lr >>>>>>>> >>>>>>>> That is five instructions long. >>>>>>> >>>>>>> On ppc32 I get: >>>>>>> >>>>>>> 00000094 : >>>>>>> 94: 3d 20 00 00 lis r9,0 >>>>>>> 96: R_PPC_ADDR16_HA .data..ro_after_init >>>>>>> 98: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> 9c: 39 29 00 00 addi r9,r9,0 >>>>>>> 9e: R_PPC_ADDR16_LO .data..ro_after_init >>>>>>> a0: 7d 29 20 2e lwzx r9,r9,r4 >>>>>>> a4: 91 23 00 00 stw r9,0(r3) >>>>>>> a8: 4e 80 00 20 blr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please show that your new implementation is not more expensive on >>>>>>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >>>>>>>> the disassembly. >>>>>>> >>>>>>> With your series I get: >>>>>>> >>>>>>> 00000000 : >>>>>>> 0: 3d 20 00 00 lis r9,0 >>>>>>> 2: R_PPC_ADDR16_HA .rodata >>>>>>> 4: 39 29 00 00 addi r9,r9,0 >>>>>>> 6: R_PPC_ADDR16_LO .rodata >>>>>>> 8: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> c: 7d 49 20 2e lwzx r10,r9,r4 >>>>>>> 10: 7d 4a 4a 14 add r10,r10,r9 >>>>>>> 14: 7d 49 03 a6 mtctr r10 >>>>>>> 18: 4e 80 04 20 bctr >>>>>>> 1c: 39 20 03 15 li r9,789 >>>>>>> 20: 91 23 00 00 stw r9,0(r3) >>>>>>> 24: 4e 80 00 20 blr >>>>>>> 28: 39 20 01 15 li r9,277 >>>>>>> 2c: 91 23 00 00 stw r9,0(r3) >>>>>>> 30: 4e 80 00 20 blr >>>>>>> 34: 39 20 07 15 li r9,1813 >>>>>>> 38: 91 23 00 00 stw r9,0(r3) >>>>>>> 3c: 4e 80 00 20 blr >>>>>>> 40: 39 20 05 15 li r9,1301 >>>>>>> 44: 91 23 00 00 stw r9,0(r3) >>>>>>> 48: 4e 80 00 20 blr >>>>>>> 4c: 39 20 01 11 li r9,273 >>>>>>> 50: 4b ff ff d0 b 20 >>>>>>> >>>>>>> >>>>>>> That is definitely more expensive, it implements a table of branches. >>>>>> >>>>>> Okay, will split out the PPC32 implementation that retains existing >>>>>> table look up method. Also planning to keep that inside same file >>>>>> (arch/powerpc/mm/mmap.c), unless you have a difference preference. >>>>> >>>>> My point was not to get something specific for PPC32, but to amplify on >>>>> Russell's objection. >>>>> >>>>> As this is bad for ARM and bad for PPC32, do we have any evidence that >>>>> your change is good for any other architecture ? >>>>> >>>>> I checked PPC64 and there is exactly the same drawback. With the current >>>>> implementation it is a small function performing table read then a few >>>>> adjustment. After your change it is a bigger function implementing a >>>>> table of branches. >>>> >>>> I am wondering if this would not be the case for any other switch case >>>> statement on the platform ? Is there something specific/different just >>>> on vm_get_page_prot() implementation ? Are you suggesting that switch >>>> case statements should just be avoided instead ? >>>> >>>>> >>>>> So, as requested by Russell, could you look at the disassembly for other >>>>> architectures and show us that ARM and POWERPC are the only ones for >>>>> which your change is not optimal ? >>>> >>>> But the primary purpose of this series is not to guarantee optimized >>>> code on platform by platform basis, while migrating from a table based >>>> look up method into a switch case statement. >>>> >>>> But instead, the purposes is to remove current levels of unnecessary >>>> abstraction while converting a vm_flags access combination into page >>>> protection. The switch case statement for platform implementation of >>>> vm_get_page_prot() just seemed logical enough. Christoph's original >>>> suggestion patch for x86 had the same implementation as well. >>>> >>>> But if the table look up is still better/preferred method on certain >>>> platforms like arm or ppc32, will be happy to preserve that. >>> >>> I doubt the switch() variant would give better code on any platform. >>> >>> What about using tables everywhere, using designated initializers >>> to improve readability? >> >> Designated initializers ? Could you please be more specific. A table look >> up on arm platform would be something like this and arm_protection_map[] >> needs to be updated with user_pgprot like before. Just wondering how a >> designated initializer will help here. > > It's more readable than the original: > > pgprot_t protection_map[16] __ro_after_init = { > __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, > __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 > }; > >> >> static pgprot_t arm_protection_map[16] __ro_after_init = { >> [VM_NONE] = __PAGE_NONE, >> [VM_READ] = __PAGE_READONLY, >> [VM_WRITE] = __PAGE_COPY, >> [VM_WRITE | VM_READ] = __PAGE_COPY, >> [VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC, >> [VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC, >> [VM_SHARED] = __PAGE_NONE, >> [VM_SHARED | VM_READ] = __PAGE_READONLY, >> [VM_SHARED | VM_WRITE] = __PAGE_SHARED, >> [VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED, >> [VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC >> }; > > Yeah, like that. > > Seems like you already made such a conversion in > https://lore.kernel.org/all/1645425519-9034-3-git-send-email-anshuman.khandual@arm.com/ Will rework the series in two different phases as mentioned on the other thread. 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 36F68C433EF for ; Wed, 9 Mar 2022 11:34:54 +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=/44V5dUuhsc7c0whQ9Dk8rcdcEmHuiJmB6JVUI3D0DA=; b=Z0aZQSSBY3zkdW IHmiN/sB0kj7T73CFK3EKvpYLdevPlH4E7rOQ1UQIm3n8Ul3Lp0u7O0ejYHT4NMCaP1MyfG20m/KG CPU7BHmV36xaFPoQOB5TvsJz1rG3cFPqEhQg2NsZ5okUmAe5a1GyezHTyFSGNcb7UBPFCidC5RH7T YRGkYKcBnRnkeIRB3tiK4QzjpMwaZrY1mJ9iIMQZaeXkEfq79fFNEoB35/OrOXm+lGHixebeo4oRW 8yAmBJp4z7SOJtBFCbpzDdyt+fdZ5fU7Q9l9L+xwehddTJWW3SEQyzx4PJa/Ej9YN/Hxre46PPpy3 evqNBcLPX41w4EieFhAA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZd-008Iph-Ns; Wed, 09 Mar 2022 11:33:45 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRuZY-008Inh-NB; Wed, 09 Mar 2022 11:33:42 +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 C45AC1655; Wed, 9 Mar 2022 03:33:39 -0800 (PST) Received: from [10.163.33.203] (unknown [10.163.33.203]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3A213FA4D; Wed, 9 Mar 2022 03:33:29 -0800 (PST) Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> Date: Wed, 9 Mar 2022 17:03:28 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Content-Language: en-US To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> From: Anshuman Khandual In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_033340_881436_76421664 X-CRM114-Status: GOOD ( 32.32 ) 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="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgpPbiAzLzIvMjIgMTY6NDQsIEdlZXJ0IFV5dHRlcmhvZXZlbiB3cm90ZToKPiBIaSBBbnNodW1h biwKPiAKPiBPbiBXZWQsIE1hciAyLCAyMDIyIGF0IDEyOjA3IFBNIEFuc2h1bWFuIEtoYW5kdWFs Cj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+IHdyb3RlOgo+PiBPbiAzLzIvMjIgMzozNSBQ TSwgR2VlcnQgVXl0dGVyaG9ldmVuIHdyb3RlOgo+Pj4gT24gV2VkLCBNYXIgMiwgMjAyMiBhdCAx MDo1MSBBTSBBbnNodW1hbiBLaGFuZHVhbAo+Pj4gPGFuc2h1bWFuLmtoYW5kdWFsQGFybS5jb20+ IHdyb3RlOgo+Pj4+IE9uIDMvMi8yMiAxMjozNSBQTSwgQ2hyaXN0b3BoZSBMZXJveSB3cm90ZToK Pj4+Pj4gTGUgMDIvMDMvMjAyMiDDoCAwNDoyMiwgQW5zaHVtYW4gS2hhbmR1YWwgYSDDqWNyaXQg Ogo+Pj4+Pj4gT24gMy8xLzIyIDE6NDYgUE0sIENocmlzdG9waGUgTGVyb3kgd3JvdGU6Cj4+Pj4+ Pj4gTGUgMDEvMDMvMjAyMiDDoCAwMTozMSwgUnVzc2VsbCBLaW5nIChPcmFjbGUpIGEgw6ljcml0 IDoKPj4+Pj4+Pj4gT24gVHVlLCBNYXIgMDEsIDIwMjIgYXQgMDU6MzA6NDFBTSArMDUzMCwgQW5z aHVtYW4gS2hhbmR1YWwgd3JvdGU6Cj4+Pj4+Pj4+PiBPbiAyLzI4LzIyIDQ6MjcgUE0sIFJ1c3Nl bGwgS2luZyAoT3JhY2xlKSB3cm90ZToKPj4+Pj4+Pj4+PiBPbiBNb24sIEZlYiAyOCwgMjAyMiBh dCAwNDoxNzozMlBNICswNTMwLCBBbnNodW1hbiBLaGFuZHVhbCB3cm90ZToKPj4+Pj4+Pj4+Pj4g VGhpcyBkZWZpbmVzIGFuZCBleHBvcnRzIGEgcGxhdGZvcm0gc3BlY2lmaWMgY3VzdG9tIHZtX2dl dF9wYWdlX3Byb3QoKSB2aWEKPj4+Pj4+Pj4+Pj4gc3Vic2NyaWJpbmcgQVJDSF9IQVNfVk1fR0VU X1BBR0VfUFJPVC4gU3Vic2VxdWVudGx5IGFsbCBfX1NYWFggYW5kIF9fUFhYWAo+Pj4+Pj4+Pj4+ PiBtYWNyb3MgY2FuIGJlIGRyb3BwZWQgd2hpY2ggYXJlIG5vIGxvbmdlciBuZWVkZWQuCj4+Pj4+ Pj4+Pj4KPj4+Pj4+Pj4+PiBXaGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8ga25vdyBpcyB3aHkg aGF2aW5nIHRvIHJ1biBfY29kZV8gdG8gd29yayBvdXQKPj4+Pj4+Pj4+PiB3aGF0IHRoZSBwYWdl IHByb3RlY3Rpb25zIG5lZWQgdG8gYmUgaXMgYmV0dGVyIHRoYW4gbG9va2luZyBpdCB1cCBpbiBh Cj4+Pj4+Pj4+Pj4gdGFibGUuCj4+Pj4+Pj4+Pj4KPj4+Pj4+Pj4+PiBOb3Qgb25seSBpcyB0aGlz IG1vcmUgZXhwZW5zaXZlIGluIHRlcm1zIG9mIENQVSBjeWNsZXMsIGl0IGFsc28gYnJpbmdzCj4+ Pj4+Pj4+Pj4gYWRkaXRpb25hbCBjb2RlIHNpemUgd2l0aCBpdC4KPj4+Pj4+Pj4+Pgo+Pj4+Pj4+ Pj4+IEknbSBzdHJ1Z2dsaW5nIHRvIHNlZSB3aGF0IHRoZSBiZW5lZml0IGlzLgo+Pj4+Pj4+Pj4K Pj4+Pj4+Pj4+IEN1cnJlbnRseSB2bV9nZXRfcGFnZV9wcm90KCkgaXMgYWxzbyBiZWluZyBfcnVu XyB0byBmZXRjaCByZXF1aXJlZCBwYWdlCj4+Pj4+Pj4+PiBwcm90ZWN0aW9uIHZhbHVlcy4gQWx0 aG91Z2ggdGhhdCBpcyBiZWluZyBydW4gaW4gdGhlIGNvcmUgTU0gYW5kIGZyb20gYQo+Pj4+Pj4+ Pj4gcGxhdGZvcm0gcGVyc3BlY3RpdmUgX19TWFhYLCBfX1BYWFggYXJlIGp1c3QgYmVpbmcgZXhw b3J0ZWQgZm9yIGEgdGFibGUuCj4+Pj4+Pj4+PiBMb29raW5nIGl0IHVwIGluIGEgdGFibGUgKGFu ZCBhcHBseWluZyBtb3JlIGNvbnN0cnVjdHMgdGhlcmUgYWZ0ZXIpIGlzCj4+Pj4+Pj4+PiBub3Qg bXVjaCBkaWZmZXJlbnQgdGhhbiBhIGNsZWFuIHN3aXRjaCBjYXNlIHN0YXRlbWVudCBpbiB0ZXJt cyBvZiBDUFUKPj4+Pj4+Pj4+IHVzYWdlLiBTbyB0aGlzIGlzIG5vdCBtb3JlIGV4cGVuc2l2ZSBp biB0ZXJtcyBvZiBDUFUgY3ljbGVzLgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBJIGRpc2FncmVlLgo+Pj4+ Pj4+Cj4+Pj4+Pj4gU28gZG8gSS4KPj4+Pj4+Pgo+Pj4+Pj4+Pgo+Pj4+Pj4+PiBIb3dldmVyLCBs ZXQncyBiYXNlIHRoaXMgZGlzYWdyZWVtZW50IG9uIHNvbWUgZXZpZGVuY2UuIEhlcmUgaXMgdGhl Cj4+Pj4+Pj4+IHByZXNlbnQgMzItYml0IEFSTSBpbXBsZW1lbnRhdGlvbjoKPj4+Pj4+Pj4KPj4+ Pj4+Pj4gMDAwMDAwNDggPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+PiAgICAgICAgIDQ4OiAg ICAgICBlMjAwMDAwZiAgICAgICAgYW5kICAgICByMCwgcjAsICMxNQo+Pj4+Pj4+PiAgICAgICAg IDRjOiAgICAgICBlMzAwMzAwMCAgICAgICAgbW92dyAgICByMywgIzAKPj4+Pj4+Pj4gICAgICAg ICAgICAgICAgICAgICAgICAgICA0YzogUl9BUk1fTU9WV19BQlNfTkMgICAuTEFOQ0hPUjEKPj4+ Pj4+Pj4gICAgICAgICA1MDogICAgICAgZTM0MDMwMDAgICAgICAgIG1vdnQgICAgcjMsICMwCj4+ Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgNTA6IFJfQVJNX01PVlRfQUJTICAgICAg LkxBTkNIT1IxCj4+Pj4+Pj4+ICAgICAgICAgNTQ6ICAgICAgIGU3OTMwMTAwICAgICAgICBsZHIg ICAgIHIwLCBbcjMsIHIwLCBsc2wgIzJdCj4+Pj4+Pj4+ICAgICAgICAgNTg6ICAgICAgIGUxMmZm ZjFlICAgICAgICBieCAgICAgIGxyCj4+Pj4+Pj4+Cj4+Pj4+Pj4+IFRoYXQgaXMgZml2ZSBpbnN0 cnVjdGlvbnMgbG9uZy4KPj4+Pj4+Pgo+Pj4+Pj4+IE9uIHBwYzMyIEkgZ2V0Ogo+Pj4+Pj4+Cj4+ Pj4+Pj4gMDAwMDAwOTQgPHZtX2dldF9wYWdlX3Byb3Q+Ogo+Pj4+Pj4+ICAgICAgICAgOTQ6IDNk IDIwIDAwIDAwICAgICBsaXMgICAgIHI5LDAKPj4+Pj4+PiAgICAgICAgICAgICAgICAgICAgIDk2 OiBSX1BQQ19BRERSMTZfSEEgICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+Pj4+Pj4gICAgICAg ICA5ODogNTQgODQgMTYgYmEgICAgIHJsd2lubSAgcjQscjQsMiwyNiwyOQo+Pj4+Pj4+ICAgICAg ICAgOWM6IDM5IDI5IDAwIDAwICAgICBhZGRpICAgIHI5LHI5LDAKPj4+Pj4+PiAgICAgICAgICAg ICAgICAgICAgIDllOiBSX1BQQ19BRERSMTZfTE8gICAgIC5kYXRhLi5yb19hZnRlcl9pbml0Cj4+ Pj4+Pj4gICAgICAgICBhMDogN2QgMjkgMjAgMmUgICAgIGx3enggICAgcjkscjkscjQKPj4+Pj4+ PiAgICAgICAgIGE0OiA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAg ICAgICAgYTg6IDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+Pgo+Pj4+Pj4+Cj4+Pj4+Pj4+Cj4+ Pj4+Pj4+IFBsZWFzZSBzaG93IHRoYXQgeW91ciBuZXcgaW1wbGVtZW50YXRpb24gaXMgbm90IG1v cmUgZXhwZW5zaXZlIG9uCj4+Pj4+Pj4+IDMyLWJpdCBBUk0uIFBsZWFzZSBkbyBzbyBieSBidWls ZGluZyBhIDMyLWJpdCBrZXJuZWwsIGFuZCBwcm92aWRpbmcKPj4+Pj4+Pj4gdGhlIGRpc2Fzc2Vt Ymx5Lgo+Pj4+Pj4+Cj4+Pj4+Pj4gV2l0aCB5b3VyIHNlcmllcyBJIGdldDoKPj4+Pj4+Pgo+Pj4+ Pj4+IDAwMDAwMDAwIDx2bV9nZXRfcGFnZV9wcm90PjoKPj4+Pj4+PiAgICAgIDA6ICAgICAzZCAy MCAwMCAwMCAgICAgbGlzICAgICByOSwwCj4+Pj4+Pj4gICAgICAgICAgICAgICAgICAgICAyOiBS X1BQQ19BRERSMTZfSEEgICAgICAucm9kYXRhCj4+Pj4+Pj4gICAgICA0OiAgICAgMzkgMjkgMDAg MDAgICAgIGFkZGkgICAgcjkscjksMAo+Pj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgNjogUl9Q UENfQUREUjE2X0xPICAgICAgLnJvZGF0YQo+Pj4+Pj4+ICAgICAgODogICAgIDU0IDg0IDE2IGJh ICAgICBybHdpbm0gIHI0LHI0LDIsMjYsMjkKPj4+Pj4+PiAgICAgIGM6ICAgICA3ZCA0OSAyMCAy ZSAgICAgbHd6eCAgICByMTAscjkscjQKPj4+Pj4+PiAgICAgMTA6ICAgICA3ZCA0YSA0YSAxNCAg ICAgYWRkICAgICByMTAscjEwLHI5Cj4+Pj4+Pj4gICAgIDE0OiAgICAgN2QgNDkgMDMgYTYgICAg IG10Y3RyICAgcjEwCj4+Pj4+Pj4gICAgIDE4OiAgICAgNGUgODAgMDQgMjAgICAgIGJjdHIKPj4+ Pj4+PiAgICAgMWM6ICAgICAzOSAyMCAwMyAxNSAgICAgbGkgICAgICByOSw3ODkKPj4+Pj4+PiAg ICAgMjA6ICAgICA5MSAyMyAwMCAwMCAgICAgc3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAy NDogICAgIDRlIDgwIDAwIDIwICAgICBibHIKPj4+Pj4+PiAgICAgMjg6ICAgICAzOSAyMCAwMSAx NSAgICAgbGkgICAgICByOSwyNzcKPj4+Pj4+PiAgICAgMmM6ICAgICA5MSAyMyAwMCAwMCAgICAg c3R3ICAgICByOSwwKHIzKQo+Pj4+Pj4+ICAgICAzMDogICAgIDRlIDgwIDAwIDIwICAgICBibHIK Pj4+Pj4+PiAgICAgMzQ6ICAgICAzOSAyMCAwNyAxNSAgICAgbGkgICAgICByOSwxODEzCj4+Pj4+ Pj4gICAgIDM4OiAgICAgOTEgMjMgMDAgMDAgICAgIHN0dyAgICAgcjksMChyMykKPj4+Pj4+PiAg ICAgM2M6ICAgICA0ZSA4MCAwMCAyMCAgICAgYmxyCj4+Pj4+Pj4gICAgIDQwOiAgICAgMzkgMjAg MDUgMTUgICAgIGxpICAgICAgcjksMTMwMQo+Pj4+Pj4+ICAgICA0NDogICAgIDkxIDIzIDAwIDAw ICAgICBzdHcgICAgIHI5LDAocjMpCj4+Pj4+Pj4gICAgIDQ4OiAgICAgNGUgODAgMDAgMjAgICAg IGJscgo+Pj4+Pj4+ICAgICA0YzogICAgIDM5IDIwIDAxIDExICAgICBsaSAgICAgIHI5LDI3Mwo+ Pj4+Pj4+ICAgICA1MDogICAgIDRiIGZmIGZmIGQwICAgICBiICAgICAgIDIwIDx2bV9nZXRfcGFn ZV9wcm90KzB4MjA+Cj4+Pj4+Pj4KPj4+Pj4+Pgo+Pj4+Pj4+IFRoYXQgaXMgZGVmaW5pdGVseSBt b3JlIGV4cGVuc2l2ZSwgaXQgaW1wbGVtZW50cyBhIHRhYmxlIG9mIGJyYW5jaGVzLgo+Pj4+Pj4K Pj4+Pj4+IE9rYXksIHdpbGwgc3BsaXQgb3V0IHRoZSBQUEMzMiBpbXBsZW1lbnRhdGlvbiB0aGF0 IHJldGFpbnMgZXhpc3RpbmcKPj4+Pj4+IHRhYmxlIGxvb2sgdXAgbWV0aG9kLiBBbHNvIHBsYW5u aW5nIHRvIGtlZXAgdGhhdCBpbnNpZGUgc2FtZSBmaWxlCj4+Pj4+PiAoYXJjaC9wb3dlcnBjL21t L21tYXAuYyksIHVubGVzcyB5b3UgaGF2ZSBhIGRpZmZlcmVuY2UgcHJlZmVyZW5jZS4KPj4+Pj4K Pj4+Pj4gTXkgcG9pbnQgd2FzIG5vdCB0byBnZXQgc29tZXRoaW5nIHNwZWNpZmljIGZvciBQUEMz MiwgYnV0IHRvIGFtcGxpZnkgb24KPj4+Pj4gUnVzc2VsbCdzIG9iamVjdGlvbi4KPj4+Pj4KPj4+ Pj4gQXMgdGhpcyBpcyBiYWQgZm9yIEFSTSBhbmQgYmFkIGZvciBQUEMzMiwgZG8gd2UgaGF2ZSBh bnkgZXZpZGVuY2UgdGhhdAo+Pj4+PiB5b3VyIGNoYW5nZSBpcyBnb29kIGZvciBhbnkgb3RoZXIg YXJjaGl0ZWN0dXJlID8KPj4+Pj4KPj4+Pj4gSSBjaGVja2VkIFBQQzY0IGFuZCB0aGVyZSBpcyBl eGFjdGx5IHRoZSBzYW1lIGRyYXdiYWNrLiBXaXRoIHRoZSBjdXJyZW50Cj4+Pj4+IGltcGxlbWVu dGF0aW9uIGl0IGlzIGEgc21hbGwgZnVuY3Rpb24gcGVyZm9ybWluZyB0YWJsZSByZWFkIHRoZW4g YSBmZXcKPj4+Pj4gYWRqdXN0bWVudC4gQWZ0ZXIgeW91ciBjaGFuZ2UgaXQgaXMgYSBiaWdnZXIg ZnVuY3Rpb24gaW1wbGVtZW50aW5nIGEKPj4+Pj4gdGFibGUgb2YgYnJhbmNoZXMuCj4+Pj4KPj4+ PiBJIGFtIHdvbmRlcmluZyBpZiB0aGlzIHdvdWxkIG5vdCBiZSB0aGUgY2FzZSBmb3IgYW55IG90 aGVyIHN3aXRjaCBjYXNlCj4+Pj4gc3RhdGVtZW50IG9uIHRoZSBwbGF0Zm9ybSA/IElzIHRoZXJl IHNvbWV0aGluZyBzcGVjaWZpYy9kaWZmZXJlbnQganVzdAo+Pj4+IG9uIHZtX2dldF9wYWdlX3By b3QoKSBpbXBsZW1lbnRhdGlvbiA/IEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHN3aXRjaAo+Pj4+ IGNhc2Ugc3RhdGVtZW50cyBzaG91bGQganVzdCBiZSBhdm9pZGVkIGluc3RlYWQgPwo+Pj4+Cj4+ Pj4+Cj4+Pj4+IFNvLCBhcyByZXF1ZXN0ZWQgYnkgUnVzc2VsbCwgY291bGQgeW91IGxvb2sgYXQg dGhlIGRpc2Fzc2VtYmx5IGZvciBvdGhlcgo+Pj4+PiBhcmNoaXRlY3R1cmVzIGFuZCBzaG93IHVz IHRoYXQgQVJNIGFuZCBQT1dFUlBDIGFyZSB0aGUgb25seSBvbmVzIGZvcgo+Pj4+PiB3aGljaCB5 b3VyIGNoYW5nZSBpcyBub3Qgb3B0aW1hbCA/Cj4+Pj4KPj4+PiBCdXQgdGhlIHByaW1hcnkgcHVy cG9zZSBvZiB0aGlzIHNlcmllcyBpcyBub3QgdG8gZ3VhcmFudGVlIG9wdGltaXplZAo+Pj4+IGNv ZGUgb24gcGxhdGZvcm0gYnkgcGxhdGZvcm0gYmFzaXMsIHdoaWxlIG1pZ3JhdGluZyBmcm9tIGEg dGFibGUgYmFzZWQKPj4+PiBsb29rIHVwIG1ldGhvZCBpbnRvIGEgc3dpdGNoIGNhc2Ugc3RhdGVt ZW50Lgo+Pj4+Cj4+Pj4gQnV0IGluc3RlYWQsIHRoZSBwdXJwb3NlcyBpcyB0byByZW1vdmUgY3Vy cmVudCBsZXZlbHMgb2YgdW5uZWNlc3NhcnkKPj4+PiBhYnN0cmFjdGlvbiB3aGlsZSBjb252ZXJ0 aW5nIGEgdm1fZmxhZ3MgYWNjZXNzIGNvbWJpbmF0aW9uIGludG8gcGFnZQo+Pj4+IHByb3RlY3Rp b24uIFRoZSBzd2l0Y2ggY2FzZSBzdGF0ZW1lbnQgZm9yIHBsYXRmb3JtIGltcGxlbWVudGF0aW9u IG9mCj4+Pj4gdm1fZ2V0X3BhZ2VfcHJvdCgpIGp1c3Qgc2VlbWVkIGxvZ2ljYWwgZW5vdWdoLiBD aHJpc3RvcGgncyBvcmlnaW5hbAo+Pj4+IHN1Z2dlc3Rpb24gcGF0Y2ggZm9yIHg4NiBoYWQgdGhl IHNhbWUgaW1wbGVtZW50YXRpb24gYXMgd2VsbC4KPj4+Pgo+Pj4+IEJ1dCBpZiB0aGUgdGFibGUg bG9vayB1cCBpcyBzdGlsbCBiZXR0ZXIvcHJlZmVycmVkIG1ldGhvZCBvbiBjZXJ0YWluCj4+Pj4g cGxhdGZvcm1zIGxpa2UgYXJtIG9yIHBwYzMyLCB3aWxsIGJlIGhhcHB5IHRvIHByZXNlcnZlIHRo YXQuCj4+Pgo+Pj4gSSBkb3VidCB0aGUgc3dpdGNoKCkgdmFyaWFudCB3b3VsZCBnaXZlIGJldHRl ciBjb2RlIG9uIGFueSBwbGF0Zm9ybS4KPj4+Cj4+PiBXaGF0IGFib3V0IHVzaW5nIHRhYmxlcyBl dmVyeXdoZXJlLCB1c2luZyBkZXNpZ25hdGVkIGluaXRpYWxpemVycwo+Pj4gdG8gaW1wcm92ZSBy ZWFkYWJpbGl0eT8KPj4KPj4gRGVzaWduYXRlZCBpbml0aWFsaXplcnMgPyBDb3VsZCB5b3UgcGxl YXNlIGJlIG1vcmUgc3BlY2lmaWMuIEEgdGFibGUgbG9vawo+PiB1cCBvbiBhcm0gcGxhdGZvcm0g d291bGQgYmUgc29tZXRoaW5nIGxpa2UgdGhpcyBhbmQgYXJtX3Byb3RlY3Rpb25fbWFwW10KPj4g bmVlZHMgdG8gYmUgdXBkYXRlZCB3aXRoIHVzZXJfcGdwcm90IGxpa2UgYmVmb3JlLiBKdXN0IHdv bmRlcmluZyBob3cgYQo+PiBkZXNpZ25hdGVkIGluaXRpYWxpemVyIHdpbGwgaGVscCBoZXJlLgo+ IAo+IEl0J3MgbW9yZSByZWFkYWJsZSB0aGFuIHRoZSBvcmlnaW5hbDoKPiAKPiAgICAgcGdwcm90 X3QgcHJvdGVjdGlvbl9tYXBbMTZdIF9fcm9fYWZ0ZXJfaW5pdCA9IHsKPiAgICAgICAgICAgICBf X1AwMDAsIF9fUDAwMSwgX19QMDEwLCBfX1AwMTEsIF9fUDEwMCwgX19QMTAxLCBfX1AxMTAsIF9f UDExMSwKPiAgICAgICAgICAgICBfX1MwMDAsIF9fUzAwMSwgX19TMDEwLCBfX1MwMTEsIF9fUzEw MCwgX19TMTAxLCBfX1MxMTAsIF9fUzExMQo+ICAgICB9Owo+IAo+Pgo+PiBzdGF0aWMgcGdwcm90 X3QgYXJtX3Byb3RlY3Rpb25fbWFwWzE2XSBfX3JvX2FmdGVyX2luaXQgPSB7Cj4+ICAgICAgICBb Vk1fTk9ORV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9O T05FLAo+PiAgICAgICAgW1ZNX1JFQURdICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPSBfX1BBR0VfUkVBRE9OTFksCj4+ICAgICAgICBbVk1fV1JJVEVdICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9DT1BZLAo+PiAgICAgICAgW1ZNX1dS SVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWSwK Pj4gICAgICAgIFtWTV9FWEVDXSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1fRVhFQyB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgICAgICAgICAgICA9IF9fUEFHRV9SRUFET05MWV9FWEVDLAo+PiAgICAg ICAgW1ZNX0VYRUMgfCBWTV9XUklURV0gICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX0VYRUMgfCBWTV9XUklURSB8IFZNX1JFQURdICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfQ09QWV9FWEVDLAo+PiAgICAgICAgW1ZNX1NIQVJFRF0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BBR0VfTk9ORSwKPj4gICAg ICAgIFtWTV9TSEFSRUQgfCBWTV9SRUFEXSAgICAgICAgICAgICAgICAgICAgICAgICAgID0gX19Q QUdFX1JFQURPTkxZLAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZNX1dSSVRFXSAgICAgICAgICAg ICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAgICAgW1ZNX1NIQVJFRCB8IFZN X1dSSVRFIHwgVk1fUkVBRF0gICAgICAgICAgICAgICAgPSBfX1BBR0VfU0hBUkVELAo+PiAgICAg ICAgW1ZNX1NIQVJFRCB8IFZNX0VYRUNdICAgICAgICAgICAgICAgICAgICAgICAgICAgPSBfX1BB R0VfUkVBRE9OTFlfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fUkVB RF0gICAgICAgICAgICAgICAgID0gX19QQUdFX1JFQURPTkxZX0VYRUMsCj4+ICAgICAgICBbVk1f U0hBUkVEIHwgVk1fRVhFQyB8IFZNX1dSSVRFXSAgICAgICAgICAgICAgICA9IF9fUEFHRV9TSEFS RURfRVhFQywKPj4gICAgICAgIFtWTV9TSEFSRUQgfCBWTV9FWEVDIHwgVk1fV1JJVEUgfCBWTV9S RUFEXSAgICAgID0gX19QQUdFX1NIQVJFRF9FWEVDCj4+IH07Cj4gCj4gWWVhaCwgbGlrZSB0aGF0 Lgo+IAo+IFNlZW1zIGxpa2UgeW91IGFscmVhZHkgbWFkZSBzdWNoIGEgY29udmVyc2lvbiBpbgo+ IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2FsbC8xNjQ1NDI1NTE5LTkwMzQtMy1naXQtc2VuZC1l bWFpbC1hbnNodW1hbi5raGFuZHVhbEBhcm0uY29tLwoKV2lsbCByZXdvcmsgdGhlIHNlcmllcyBp biB0d28gZGlmZmVyZW50IHBoYXNlcyBhcyBtZW50aW9uZWQgb24gdGhlIG90aGVyIHRocmVhZC4K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFy bS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y ZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1r ZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Date: Wed, 9 Mar 2022 17:03:28 +0530 Subject: [OpenRISC] [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT In-Reply-To: References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: openrisc@lists.librecores.org On 3/2/22 16:44, Geert Uytterhoeven wrote: > Hi Anshuman, > > On Wed, Mar 2, 2022 at 12:07 PM Anshuman Khandual > wrote: >> On 3/2/22 3:35 PM, Geert Uytterhoeven wrote: >>> On Wed, Mar 2, 2022 at 10:51 AM Anshuman Khandual >>> wrote: >>>> On 3/2/22 12:35 PM, Christophe Leroy wrote: >>>>> Le 02/03/2022 à 04:22, Anshuman Khandual a écrit : >>>>>> On 3/1/22 1:46 PM, Christophe Leroy wrote: >>>>>>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >>>>>>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>>>>>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>>>>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>>>>>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>>>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>>>>>>>> macros can be dropped which are no longer needed. >>>>>>>>>> >>>>>>>>>> What I would really like to know is why having to run _code_ to work out >>>>>>>>>> what the page protections need to be is better than looking it up in a >>>>>>>>>> table. >>>>>>>>>> >>>>>>>>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>>>>>>>> additional code size with it. >>>>>>>>>> >>>>>>>>>> I'm struggling to see what the benefit is. >>>>>>>>> >>>>>>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>>>>>>>> protection values. Although that is being run in the core MM and from a >>>>>>>>> platform perspective __SXXX, __PXXX are just being exported for a table. >>>>>>>>> Looking it up in a table (and applying more constructs there after) is >>>>>>>>> not much different than a clean switch case statement in terms of CPU >>>>>>>>> usage. So this is not more expensive in terms of CPU cycles. >>>>>>>> >>>>>>>> I disagree. >>>>>>> >>>>>>> So do I. >>>>>>> >>>>>>>> >>>>>>>> However, let's base this disagreement on some evidence. Here is the >>>>>>>> present 32-bit ARM implementation: >>>>>>>> >>>>>>>> 00000048 : >>>>>>>> 48: e200000f and r0, r0, #15 >>>>>>>> 4c: e3003000 movw r3, #0 >>>>>>>> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >>>>>>>> 50: e3403000 movt r3, #0 >>>>>>>> 50: R_ARM_MOVT_ABS .LANCHOR1 >>>>>>>> 54: e7930100 ldr r0, [r3, r0, lsl #2] >>>>>>>> 58: e12fff1e bx lr >>>>>>>> >>>>>>>> That is five instructions long. >>>>>>> >>>>>>> On ppc32 I get: >>>>>>> >>>>>>> 00000094 : >>>>>>> 94: 3d 20 00 00 lis r9,0 >>>>>>> 96: R_PPC_ADDR16_HA .data..ro_after_init >>>>>>> 98: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> 9c: 39 29 00 00 addi r9,r9,0 >>>>>>> 9e: R_PPC_ADDR16_LO .data..ro_after_init >>>>>>> a0: 7d 29 20 2e lwzx r9,r9,r4 >>>>>>> a4: 91 23 00 00 stw r9,0(r3) >>>>>>> a8: 4e 80 00 20 blr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please show that your new implementation is not more expensive on >>>>>>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >>>>>>>> the disassembly. >>>>>>> >>>>>>> With your series I get: >>>>>>> >>>>>>> 00000000 : >>>>>>> 0: 3d 20 00 00 lis r9,0 >>>>>>> 2: R_PPC_ADDR16_HA .rodata >>>>>>> 4: 39 29 00 00 addi r9,r9,0 >>>>>>> 6: R_PPC_ADDR16_LO .rodata >>>>>>> 8: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> c: 7d 49 20 2e lwzx r10,r9,r4 >>>>>>> 10: 7d 4a 4a 14 add r10,r10,r9 >>>>>>> 14: 7d 49 03 a6 mtctr r10 >>>>>>> 18: 4e 80 04 20 bctr >>>>>>> 1c: 39 20 03 15 li r9,789 >>>>>>> 20: 91 23 00 00 stw r9,0(r3) >>>>>>> 24: 4e 80 00 20 blr >>>>>>> 28: 39 20 01 15 li r9,277 >>>>>>> 2c: 91 23 00 00 stw r9,0(r3) >>>>>>> 30: 4e 80 00 20 blr >>>>>>> 34: 39 20 07 15 li r9,1813 >>>>>>> 38: 91 23 00 00 stw r9,0(r3) >>>>>>> 3c: 4e 80 00 20 blr >>>>>>> 40: 39 20 05 15 li r9,1301 >>>>>>> 44: 91 23 00 00 stw r9,0(r3) >>>>>>> 48: 4e 80 00 20 blr >>>>>>> 4c: 39 20 01 11 li r9,273 >>>>>>> 50: 4b ff ff d0 b 20 >>>>>>> >>>>>>> >>>>>>> That is definitely more expensive, it implements a table of branches. >>>>>> >>>>>> Okay, will split out the PPC32 implementation that retains existing >>>>>> table look up method. Also planning to keep that inside same file >>>>>> (arch/powerpc/mm/mmap.c), unless you have a difference preference. >>>>> >>>>> My point was not to get something specific for PPC32, but to amplify on >>>>> Russell's objection. >>>>> >>>>> As this is bad for ARM and bad for PPC32, do we have any evidence that >>>>> your change is good for any other architecture ? >>>>> >>>>> I checked PPC64 and there is exactly the same drawback. With the current >>>>> implementation it is a small function performing table read then a few >>>>> adjustment. After your change it is a bigger function implementing a >>>>> table of branches. >>>> >>>> I am wondering if this would not be the case for any other switch case >>>> statement on the platform ? Is there something specific/different just >>>> on vm_get_page_prot() implementation ? Are you suggesting that switch >>>> case statements should just be avoided instead ? >>>> >>>>> >>>>> So, as requested by Russell, could you look at the disassembly for other >>>>> architectures and show us that ARM and POWERPC are the only ones for >>>>> which your change is not optimal ? >>>> >>>> But the primary purpose of this series is not to guarantee optimized >>>> code on platform by platform basis, while migrating from a table based >>>> look up method into a switch case statement. >>>> >>>> But instead, the purposes is to remove current levels of unnecessary >>>> abstraction while converting a vm_flags access combination into page >>>> protection. The switch case statement for platform implementation of >>>> vm_get_page_prot() just seemed logical enough. Christoph's original >>>> suggestion patch for x86 had the same implementation as well. >>>> >>>> But if the table look up is still better/preferred method on certain >>>> platforms like arm or ppc32, will be happy to preserve that. >>> >>> I doubt the switch() variant would give better code on any platform. >>> >>> What about using tables everywhere, using designated initializers >>> to improve readability? >> >> Designated initializers ? Could you please be more specific. A table look >> up on arm platform would be something like this and arm_protection_map[] >> needs to be updated with user_pgprot like before. Just wondering how a >> designated initializer will help here. > > It's more readable than the original: > > pgprot_t protection_map[16] __ro_after_init = { > __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, > __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 > }; > >> >> static pgprot_t arm_protection_map[16] __ro_after_init = { >> [VM_NONE] = __PAGE_NONE, >> [VM_READ] = __PAGE_READONLY, >> [VM_WRITE] = __PAGE_COPY, >> [VM_WRITE | VM_READ] = __PAGE_COPY, >> [VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC, >> [VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC, >> [VM_SHARED] = __PAGE_NONE, >> [VM_SHARED | VM_READ] = __PAGE_READONLY, >> [VM_SHARED | VM_WRITE] = __PAGE_SHARED, >> [VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED, >> [VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC >> }; > > Yeah, like that. > > Seems like you already made such a conversion in > https://lore.kernel.org/all/1645425519-9034-3-git-send-email-anshuman.khandual at arm.com/ Will rework the series in two different phases as mentioned on the other thread. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Date: Wed, 09 Mar 2022 11:45:28 +0000 Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Message-Id: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> List-Id: References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Arnd Bergmann , "linux-um@lists.infradead.org" , "linux-m68k@lists.linux-m68k.org" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "linux-parisc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-alpha@vger.kernel.org" , "akpm@linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" On 3/2/22 16:44, Geert Uytterhoeven wrote: > Hi Anshuman, > > On Wed, Mar 2, 2022 at 12:07 PM Anshuman Khandual > wrote: >> On 3/2/22 3:35 PM, Geert Uytterhoeven wrote: >>> On Wed, Mar 2, 2022 at 10:51 AM Anshuman Khandual >>> wrote: >>>> On 3/2/22 12:35 PM, Christophe Leroy wrote: >>>>> Le 02/03/2022 à 04:22, Anshuman Khandual a écrit : >>>>>> On 3/1/22 1:46 PM, Christophe Leroy wrote: >>>>>>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >>>>>>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>>>>>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>>>>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>>>>>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>>>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>>>>>>>> macros can be dropped which are no longer needed. >>>>>>>>>> >>>>>>>>>> What I would really like to know is why having to run _code_ to work out >>>>>>>>>> what the page protections need to be is better than looking it up in a >>>>>>>>>> table. >>>>>>>>>> >>>>>>>>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>>>>>>>> additional code size with it. >>>>>>>>>> >>>>>>>>>> I'm struggling to see what the benefit is. >>>>>>>>> >>>>>>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>>>>>>>> protection values. Although that is being run in the core MM and from a >>>>>>>>> platform perspective __SXXX, __PXXX are just being exported for a table. >>>>>>>>> Looking it up in a table (and applying more constructs there after) is >>>>>>>>> not much different than a clean switch case statement in terms of CPU >>>>>>>>> usage. So this is not more expensive in terms of CPU cycles. >>>>>>>> >>>>>>>> I disagree. >>>>>>> >>>>>>> So do I. >>>>>>> >>>>>>>> >>>>>>>> However, let's base this disagreement on some evidence. Here is the >>>>>>>> present 32-bit ARM implementation: >>>>>>>> >>>>>>>> 00000048 : >>>>>>>> 48: e200000f and r0, r0, #15 >>>>>>>> 4c: e3003000 movw r3, #0 >>>>>>>> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >>>>>>>> 50: e3403000 movt r3, #0 >>>>>>>> 50: R_ARM_MOVT_ABS .LANCHOR1 >>>>>>>> 54: e7930100 ldr r0, [r3, r0, lsl #2] >>>>>>>> 58: e12fff1e bx lr >>>>>>>> >>>>>>>> That is five instructions long. >>>>>>> >>>>>>> On ppc32 I get: >>>>>>> >>>>>>> 00000094 : >>>>>>> 94: 3d 20 00 00 lis r9,0 >>>>>>> 96: R_PPC_ADDR16_HA .data..ro_after_init >>>>>>> 98: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> 9c: 39 29 00 00 addi r9,r9,0 >>>>>>> 9e: R_PPC_ADDR16_LO .data..ro_after_init >>>>>>> a0: 7d 29 20 2e lwzx r9,r9,r4 >>>>>>> a4: 91 23 00 00 stw r9,0(r3) >>>>>>> a8: 4e 80 00 20 blr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please show that your new implementation is not more expensive on >>>>>>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >>>>>>>> the disassembly. >>>>>>> >>>>>>> With your series I get: >>>>>>> >>>>>>> 00000000 : >>>>>>> 0: 3d 20 00 00 lis r9,0 >>>>>>> 2: R_PPC_ADDR16_HA .rodata >>>>>>> 4: 39 29 00 00 addi r9,r9,0 >>>>>>> 6: R_PPC_ADDR16_LO .rodata >>>>>>> 8: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> c: 7d 49 20 2e lwzx r10,r9,r4 >>>>>>> 10: 7d 4a 4a 14 add r10,r10,r9 >>>>>>> 14: 7d 49 03 a6 mtctr r10 >>>>>>> 18: 4e 80 04 20 bctr >>>>>>> 1c: 39 20 03 15 li r9,789 >>>>>>> 20: 91 23 00 00 stw r9,0(r3) >>>>>>> 24: 4e 80 00 20 blr >>>>>>> 28: 39 20 01 15 li r9,277 >>>>>>> 2c: 91 23 00 00 stw r9,0(r3) >>>>>>> 30: 4e 80 00 20 blr >>>>>>> 34: 39 20 07 15 li r9,1813 >>>>>>> 38: 91 23 00 00 stw r9,0(r3) >>>>>>> 3c: 4e 80 00 20 blr >>>>>>> 40: 39 20 05 15 li r9,1301 >>>>>>> 44: 91 23 00 00 stw r9,0(r3) >>>>>>> 48: 4e 80 00 20 blr >>>>>>> 4c: 39 20 01 11 li r9,273 >>>>>>> 50: 4b ff ff d0 b 20 >>>>>>> >>>>>>> >>>>>>> That is definitely more expensive, it implements a table of branches. >>>>>> >>>>>> Okay, will split out the PPC32 implementation that retains existing >>>>>> table look up method. Also planning to keep that inside same file >>>>>> (arch/powerpc/mm/mmap.c), unless you have a difference preference. >>>>> >>>>> My point was not to get something specific for PPC32, but to amplify on >>>>> Russell's objection. >>>>> >>>>> As this is bad for ARM and bad for PPC32, do we have any evidence that >>>>> your change is good for any other architecture ? >>>>> >>>>> I checked PPC64 and there is exactly the same drawback. With the current >>>>> implementation it is a small function performing table read then a few >>>>> adjustment. After your change it is a bigger function implementing a >>>>> table of branches. >>>> >>>> I am wondering if this would not be the case for any other switch case >>>> statement on the platform ? Is there something specific/different just >>>> on vm_get_page_prot() implementation ? Are you suggesting that switch >>>> case statements should just be avoided instead ? >>>> >>>>> >>>>> So, as requested by Russell, could you look at the disassembly for other >>>>> architectures and show us that ARM and POWERPC are the only ones for >>>>> which your change is not optimal ? >>>> >>>> But the primary purpose of this series is not to guarantee optimized >>>> code on platform by platform basis, while migrating from a table based >>>> look up method into a switch case statement. >>>> >>>> But instead, the purposes is to remove current levels of unnecessary >>>> abstraction while converting a vm_flags access combination into page >>>> protection. The switch case statement for platform implementation of >>>> vm_get_page_prot() just seemed logical enough. Christoph's original >>>> suggestion patch for x86 had the same implementation as well. >>>> >>>> But if the table look up is still better/preferred method on certain >>>> platforms like arm or ppc32, will be happy to preserve that. >>> >>> I doubt the switch() variant would give better code on any platform. >>> >>> What about using tables everywhere, using designated initializers >>> to improve readability? >> >> Designated initializers ? Could you please be more specific. A table look >> up on arm platform would be something like this and arm_protection_map[] >> needs to be updated with user_pgprot like before. Just wondering how a >> designated initializer will help here. > > It's more readable than the original: > > pgprot_t protection_map[16] __ro_after_init = { > __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, > __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 > }; > >> >> static pgprot_t arm_protection_map[16] __ro_after_init = { >> [VM_NONE] = __PAGE_NONE, >> [VM_READ] = __PAGE_READONLY, >> [VM_WRITE] = __PAGE_COPY, >> [VM_WRITE | VM_READ] = __PAGE_COPY, >> [VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC, >> [VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC, >> [VM_SHARED] = __PAGE_NONE, >> [VM_SHARED | VM_READ] = __PAGE_READONLY, >> [VM_SHARED | VM_WRITE] = __PAGE_SHARED, >> [VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED, >> [VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC >> }; > > Yeah, like that. > > Seems like you already made such a conversion in > https://lore.kernel.org/all/1645425519-9034-3-git-send-email-anshuman.khandual@arm.com/ Will rework the series in two different phases as mentioned on the other thread. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Subject: Re: [PATCH V3 09/30] arm/mm: Enable ARCH_HAS_VM_GET_PAGE_PROT Date: Wed, 9 Mar 2022 17:03:28 +0530 Message-ID: <70a99f28-ea69-58e3-f919-85551943c0a3@arm.com> References: <1646045273-9343-1-git-send-email-anshuman.khandual@arm.com> <1646045273-9343-10-git-send-email-anshuman.khandual@arm.com> <542fa048-131e-240b-cc3a-fd4fff7ce4ba@arm.com> <52866c88-59f9-2d1c-6f5a-5afcaf23f2bb@csgroup.eu> <9caa90f5-c10d-75dd-b403-1388b7a3d296@arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="utf-8" To: Geert Uytterhoeven Cc: Christophe Leroy , "Russell King (Oracle)" , "linux-ia64@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-mm@kvack.org" , "sparclinux@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-arch@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-csky@vger.kernel.org" , Christoph Hellwig , "linux-snps-arc@lists.infradead.org" On 3/2/22 16:44, Geert Uytterhoeven wrote: > Hi Anshuman, > > On Wed, Mar 2, 2022 at 12:07 PM Anshuman Khandual > wrote: >> On 3/2/22 3:35 PM, Geert Uytterhoeven wrote: >>> On Wed, Mar 2, 2022 at 10:51 AM Anshuman Khandual >>> wrote: >>>> On 3/2/22 12:35 PM, Christophe Leroy wrote: >>>>> Le 02/03/2022 à 04:22, Anshuman Khandual a écrit : >>>>>> On 3/1/22 1:46 PM, Christophe Leroy wrote: >>>>>>> Le 01/03/2022 à 01:31, Russell King (Oracle) a écrit : >>>>>>>> On Tue, Mar 01, 2022 at 05:30:41AM +0530, Anshuman Khandual wrote: >>>>>>>>> On 2/28/22 4:27 PM, Russell King (Oracle) wrote: >>>>>>>>>> On Mon, Feb 28, 2022 at 04:17:32PM +0530, Anshuman Khandual wrote: >>>>>>>>>>> This defines and exports a platform specific custom vm_get_page_prot() via >>>>>>>>>>> subscribing ARCH_HAS_VM_GET_PAGE_PROT. Subsequently all __SXXX and __PXXX >>>>>>>>>>> macros can be dropped which are no longer needed. >>>>>>>>>> >>>>>>>>>> What I would really like to know is why having to run _code_ to work out >>>>>>>>>> what the page protections need to be is better than looking it up in a >>>>>>>>>> table. >>>>>>>>>> >>>>>>>>>> Not only is this more expensive in terms of CPU cycles, it also brings >>>>>>>>>> additional code size with it. >>>>>>>>>> >>>>>>>>>> I'm struggling to see what the benefit is. >>>>>>>>> >>>>>>>>> Currently vm_get_page_prot() is also being _run_ to fetch required page >>>>>>>>> protection values. Although that is being run in the core MM and from a >>>>>>>>> platform perspective __SXXX, __PXXX are just being exported for a table. >>>>>>>>> Looking it up in a table (and applying more constructs there after) is >>>>>>>>> not much different than a clean switch case statement in terms of CPU >>>>>>>>> usage. So this is not more expensive in terms of CPU cycles. >>>>>>>> >>>>>>>> I disagree. >>>>>>> >>>>>>> So do I. >>>>>>> >>>>>>>> >>>>>>>> However, let's base this disagreement on some evidence. Here is the >>>>>>>> present 32-bit ARM implementation: >>>>>>>> >>>>>>>> 00000048 : >>>>>>>> 48: e200000f and r0, r0, #15 >>>>>>>> 4c: e3003000 movw r3, #0 >>>>>>>> 4c: R_ARM_MOVW_ABS_NC .LANCHOR1 >>>>>>>> 50: e3403000 movt r3, #0 >>>>>>>> 50: R_ARM_MOVT_ABS .LANCHOR1 >>>>>>>> 54: e7930100 ldr r0, [r3, r0, lsl #2] >>>>>>>> 58: e12fff1e bx lr >>>>>>>> >>>>>>>> That is five instructions long. >>>>>>> >>>>>>> On ppc32 I get: >>>>>>> >>>>>>> 00000094 : >>>>>>> 94: 3d 20 00 00 lis r9,0 >>>>>>> 96: R_PPC_ADDR16_HA .data..ro_after_init >>>>>>> 98: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> 9c: 39 29 00 00 addi r9,r9,0 >>>>>>> 9e: R_PPC_ADDR16_LO .data..ro_after_init >>>>>>> a0: 7d 29 20 2e lwzx r9,r9,r4 >>>>>>> a4: 91 23 00 00 stw r9,0(r3) >>>>>>> a8: 4e 80 00 20 blr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please show that your new implementation is not more expensive on >>>>>>>> 32-bit ARM. Please do so by building a 32-bit kernel, and providing >>>>>>>> the disassembly. >>>>>>> >>>>>>> With your series I get: >>>>>>> >>>>>>> 00000000 : >>>>>>> 0: 3d 20 00 00 lis r9,0 >>>>>>> 2: R_PPC_ADDR16_HA .rodata >>>>>>> 4: 39 29 00 00 addi r9,r9,0 >>>>>>> 6: R_PPC_ADDR16_LO .rodata >>>>>>> 8: 54 84 16 ba rlwinm r4,r4,2,26,29 >>>>>>> c: 7d 49 20 2e lwzx r10,r9,r4 >>>>>>> 10: 7d 4a 4a 14 add r10,r10,r9 >>>>>>> 14: 7d 49 03 a6 mtctr r10 >>>>>>> 18: 4e 80 04 20 bctr >>>>>>> 1c: 39 20 03 15 li r9,789 >>>>>>> 20: 91 23 00 00 stw r9,0(r3) >>>>>>> 24: 4e 80 00 20 blr >>>>>>> 28: 39 20 01 15 li r9,277 >>>>>>> 2c: 91 23 00 00 stw r9,0(r3) >>>>>>> 30: 4e 80 00 20 blr >>>>>>> 34: 39 20 07 15 li r9,1813 >>>>>>> 38: 91 23 00 00 stw r9,0(r3) >>>>>>> 3c: 4e 80 00 20 blr >>>>>>> 40: 39 20 05 15 li r9,1301 >>>>>>> 44: 91 23 00 00 stw r9,0(r3) >>>>>>> 48: 4e 80 00 20 blr >>>>>>> 4c: 39 20 01 11 li r9,273 >>>>>>> 50: 4b ff ff d0 b 20 >>>>>>> >>>>>>> >>>>>>> That is definitely more expensive, it implements a table of branches. >>>>>> >>>>>> Okay, will split out the PPC32 implementation that retains existing >>>>>> table look up method. Also planning to keep that inside same file >>>>>> (arch/powerpc/mm/mmap.c), unless you have a difference preference. >>>>> >>>>> My point was not to get something specific for PPC32, but to amplify on >>>>> Russell's objection. >>>>> >>>>> As this is bad for ARM and bad for PPC32, do we have any evidence that >>>>> your change is good for any other architecture ? >>>>> >>>>> I checked PPC64 and there is exactly the same drawback. With the current >>>>> implementation it is a small function performing table read then a few >>>>> adjustment. After your change it is a bigger function implementing a >>>>> table of branches. >>>> >>>> I am wondering if this would not be the case for any other switch case >>>> statement on the platform ? Is there something specific/different just >>>> on vm_get_page_prot() implementation ? Are you suggesting that switch >>>> case statements should just be avoided instead ? >>>> >>>>> >>>>> So, as requested by Russell, could you look at the disassembly for other >>>>> architectures and show us that ARM and POWERPC are the only ones for >>>>> which your change is not optimal ? >>>> >>>> But the primary purpose of this series is not to guarantee optimized >>>> code on platform by platform basis, while migrating from a table based >>>> look up method into a switch case statement. >>>> >>>> But instead, the purposes is to remove current levels of unnecessary >>>> abstraction while converting a vm_flags access combination into page >>>> protection. The switch case statement for platform implementation of >>>> vm_get_page_prot() just seemed logical enough. Christoph's original >>>> suggestion patch for x86 had the same implementation as well. >>>> >>>> But if the table look up is still better/preferred method on certain >>>> platforms like arm or ppc32, will be happy to preserve that. >>> >>> I doubt the switch() variant would give better code on any platform. >>> >>> What about using tables everywhere, using designated initializers >>> to improve readability? >> >> Designated initializers ? Could you please be more specific. A table look >> up on arm platform would be something like this and arm_protection_map[] >> needs to be updated with user_pgprot like before. Just wondering how a >> designated initializer will help here. > > It's more readable than the original: > > pgprot_t protection_map[16] __ro_after_init = { > __P000, __P001, __P010, __P011, __P100, __P101, __P110, __P111, > __S000, __S001, __S010, __S011, __S100, __S101, __S110, __S111 > }; > >> >> static pgprot_t arm_protection_map[16] __ro_after_init = { >> [VM_NONE] = __PAGE_NONE, >> [VM_READ] = __PAGE_READONLY, >> [VM_WRITE] = __PAGE_COPY, >> [VM_WRITE | VM_READ] = __PAGE_COPY, >> [VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_EXEC | VM_WRITE] = __PAGE_COPY_EXEC, >> [VM_EXEC | VM_WRITE | VM_READ] = __PAGE_COPY_EXEC, >> [VM_SHARED] = __PAGE_NONE, >> [VM_SHARED | VM_READ] = __PAGE_READONLY, >> [VM_SHARED | VM_WRITE] = __PAGE_SHARED, >> [VM_SHARED | VM_WRITE | VM_READ] = __PAGE_SHARED, >> [VM_SHARED | VM_EXEC] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_READ] = __PAGE_READONLY_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE] = __PAGE_SHARED_EXEC, >> [VM_SHARED | VM_EXEC | VM_WRITE | VM_READ] = __PAGE_SHARED_EXEC >> }; > > Yeah, like that. > > Seems like you already made such a conversion in > https://lore.kernel.org/all/1645425519-9034-3-git-send-email-anshuman.khandual@arm.com/ Will rework the series in two different phases as mentioned on the other thread.