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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39B95C433FE for ; Wed, 29 Sep 2021 02:56:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8BE4E61350 for ; Wed, 29 Sep 2021 02:56:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8BE4E61350 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id E281894000A; Tue, 28 Sep 2021 22:56:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAEFB940009; Tue, 28 Sep 2021 22:56:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C76C594000A; Tue, 28 Sep 2021 22:56:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id B09AF940009 for ; Tue, 28 Sep 2021 22:56:53 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 635DF181DD40E for ; Wed, 29 Sep 2021 02:56:53 +0000 (UTC) X-FDA: 78639098706.33.218EEE3 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf29.hostedemail.com (Postfix) with ESMTP id B2EFE900013E for ; Wed, 29 Sep 2021 02:56:52 +0000 (UTC) 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 BDA65D6E; Tue, 28 Sep 2021 19:56:51 -0700 (PDT) Received: from [192.168.0.130] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F15653F70D; Tue, 28 Sep 2021 19:56:48 -0700 (PDT) Subject: Re: [PATCH] mm/mmap: Define index macros for protection_map[] To: Christoph Hellwig Cc: linux-mm@kvack.org, Thomas Bogendoerfer , "David S. Miller" , Andrew Morton , linux-mips@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org References: <1632712920-8171-1-git-send-email-anshuman.khandual@arm.com> From: Anshuman Khandual Message-ID: <9051a597-0229-aaf2-9aad-42509b4f621d@arm.com> Date: Wed, 29 Sep 2021 08:27:46 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf29.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B2EFE900013E X-Stat-Signature: 1z875w6415feftob8yhthqyt76fgkijk X-HE-Tag: 1632884212-376464 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9/28/21 10:12 AM, Christoph Hellwig wrote: > On Tue, Sep 28, 2021 at 08:24:43AM +0530, Anshuman Khandual wrote: >>> simple switch statement provided by each architecture. See the below >>> WIP which just works for x86 and without pagetable debugging for wher= e I >>> think we should be going. >> >> Sure, this will work as well but all platforms need to be changed at o= nce. >> Is there any platform that would not subscribe ARCH_HAS_GET_PAGE_PROT = and >> export its own vm_get_page_prot() ? AFAICS all platforms are required = to >> export __PXXX and __SXXX elements currently. >> >> This seems to be a better idea than the current proposal. Probably all= the >> vm_flags combinations, which will be used in those switch statements c= an be >> converted into macros just to improve readability. Are you planning to= send >> this as a proper patch soon ? >=20 > This was just a qu=D1=96ck WIP patch. If you have some spare time to t= ackle > it for real I'd sugget the following approach: Sure, will try and get this working. >=20 > 1) Remove the direct references to protection_map in debug_vm_pgtable.= c > 2) add the ARCH_HAS_GET_PAGE_PROT symbol that lets architectures > provide vm_get_page_prot itself and not define protection_map at al= l > in this case > 3) convert all architectures that touch protection_map to provide > vm_get_page_prot themselves > 4) mark protection_map static > 5) convert all architectures that provide arch_filter_pgprot and/or > arch_vm_get_page_prot to provide vm_get_page_prot directly and > remove those hooks > 6) remove the __S???/__P??? macros and the generic vm_get_page_prot > after providing an arch implementation for every architecture. > This can maybe simplified with a new generic version that directly > looks at PAGE_* macros, but that will need further investigation > first. >=20