From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04CD6C433F5 for ; Thu, 21 Apr 2022 03:44:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7065B6B0071; Wed, 20 Apr 2022 23:44:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B6336B0073; Wed, 20 Apr 2022 23:44:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 57DC86B0074; Wed, 20 Apr 2022 23:44:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 470796B0071 for ; Wed, 20 Apr 2022 23:44:26 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 16D916127F for ; Thu, 21 Apr 2022 03:44:26 +0000 (UTC) X-FDA: 79379493732.03.C2C59C5 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf18.hostedemail.com (Postfix) with ESMTP id ACF291C0013 for ; Thu, 21 Apr 2022 03:44:22 +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 5488E1477; Wed, 20 Apr 2022 20:44:23 -0700 (PDT) Received: from [192.168.225.231] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 441B93F766; Wed, 20 Apr 2022 20:44:15 -0700 (PDT) Message-ID: <75f444a6-4f50-4356-9e71-f72c59bf0a52@arm.com> Date: Thu, 21 Apr 2022 09:14:54 +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 -next v4 1/4] mm: page_table_check: move pxx_user_accessible_page into x86 Content-Language: en-US To: Tong Tiangen , Pasha Tatashin Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , Andrew Morton , Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , LKML , linux-mm , Linux ARM , linux-riscv@lists.infradead.org, Kefeng Wang , Guohanjun References: <20220418034444.520928-1-tongtiangen@huawei.com> <20220418034444.520928-2-tongtiangen@huawei.com> <1671baf7-046e-7c52-183f-fd654125fd67@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: ACF291C0013 X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf18.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com X-Stat-Signature: gnpxm5j45de9o9xkr1z5uhs8i51373uc X-HE-Tag: 1650512662-172242 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 4/21/22 08:35, Tong Tiangen wrote: > > > 在 2022/4/21 0:44, Pasha Tatashin 写道: >> On Wed, Apr 20, 2022 at 2:45 AM Tong Tiangen wrote: >>> >>> >>> >>> 在 2022/4/19 17:29, Anshuman Khandual 写道: >>>> >>>> >>>> On 4/18/22 09:14, Tong Tiangen wrote: >>>>> --- a/mm/page_table_check.c >>>>> +++ b/mm/page_table_check.c >>>>> @@ -10,6 +10,14 @@ >>>>>    #undef pr_fmt >>>>>    #define pr_fmt(fmt)        "page_table_check: " fmt >>>>> >>>>> +#ifndef PMD_PAGE_SIZE >>>>> +#define PMD_PAGE_SIZE       PMD_SIZE >>>>> +#endif >>>>> + >>>>> +#ifndef PUD_PAGE_SIZE >>>>> +#define PUD_PAGE_SIZE       PUD_SIZE >>>>> +#endif >>>> >>>> Why cannot PMD_SIZE/PUD_SIZE be used on every platform instead ? What is the >>>> need for using PUD_PAGE_SIZE/PMD_PAGE_SIZE ? Are they different on x86 ? >>>> . >>> >>> Hi, Pasha： >>> I checked the definitions of PMD_SIZE/PUD_SIZE and >>> PUD_PAGE_SIZE/PMD_PAGE_SIZE in x86 architecture and their use outside >>> the architecture(eg: in mm/, all used PMD_SIZE/PUD_SIZE), Would it be >>> better to use a unified PMD_SIZE/PUD_SIZE here? >> >> Hi Tong, >> >> Yes, it makes sense to use PMD_SIZE/PUD_SIZE instead of >> PUD_PAGE_SIZE/PMD_PAGE_SIZE in page_table_check to be inline with the >> rest of the mm/ >> >> Pasha >> > Hi Pasha and Anshuman: > > OK, Functional correctness is not affected here, i plan to optimize this point after this patchset is merged. As page table check is now being proposed to be supported on multiple platforms i.e arm64, riscv besides just x86, it should not have any architecture specific macros or functions. Hence please do generalize these PMD/PUD sizes in this series itself.