Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp967375pxb; Fri, 22 Apr 2022 15:32:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxj3FlbrNAuRry7nCX3ky0QXEn5q9As3enhY4qF7pWzTB1tNMT99hh/ZlPDuX3I42pvJTjw X-Received: by 2002:a17:902:f608:b0:158:29e6:c88 with SMTP id n8-20020a170902f60800b0015829e60c88mr6664811plg.174.1650666753613; Fri, 22 Apr 2022 15:32:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650666753; cv=none; d=google.com; s=arc-20160816; b=ZnV+d1icPwtRBfWvP3uAn07a+K5vePwkr1sO09JUe41VPa+WOv5BULz0DvjMR62KbQ /UUYfPDIgjoglhxidm3V2YktBy2J7DHseAM2kYIDpz+2yhvs3meVjxhAHaw5RaDOEZlv aGcFMfF5/8PueeHfHBH7bZ898YcjMh6FkqpFehW71a8W5JcI83NGrkZ71VcDZxVHgSwu RUc5dYG4otLZxPKyqObpf9ePNlKHZoV3+eoO7TZH4xsVefvuul7pAgtnUwbAX29iErGk BWJHuXAB10psixFwAB+/amOBUJPx8Hff8ezLL9i7hx1iGwFo8+gMuCNQOm54CQ6D0CX8 M2Ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id; bh=XyoYbYBO+mqkzCa5u2NA4wTicy3amn3aPxRnqvgpX9A=; b=UgvlBZtQoytAF+axiqBvmb6SsbWyfV0wHKEA10aoAZ5jQ5h/uW+c6AkvfwrghhTJX8 eMBs4btkC1VPBAXvol1I6sMd9t6LP1/bbc7aXLo8MOggdihosavDBCfzrtILyM8zcG4f +juUgP593Onvzm7Xzj9G/n6ZVcmO4ohqBxo2Ol0Nn2+c0+GuKq1TKGl3jVDXH1Bsu24p Lg0vG8K3nZ1HNDpyIo5/qhhPfO6ClPC6IdbRXJHr1cRHRG7DV+XFTzFQkq2HXoaA/fo2 UbuXDTAwv4XxVK1dqCB5Hf0qWtd58l4emGwSnjPs5B2k2iRavMunsJLjZjLwrDZxegNl j81w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z21-20020a62d115000000b0050cf9f63fb0si1558552pfg.185.2022.04.22.15.32.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 15:32:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 234024169E7; Fri, 22 Apr 2022 13:46:00 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383871AbiDUDIv (ORCPT + 99 others); Wed, 20 Apr 2022 23:08:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54104 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356624AbiDUDIt (ORCPT ); Wed, 20 Apr 2022 23:08:49 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C898F10F3 for ; Wed, 20 Apr 2022 20:06:01 -0700 (PDT) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.54]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KkMpx4VcFzfYpj; Thu, 21 Apr 2022 11:05:13 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 21 Apr 2022 11:05:59 +0800 Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 21 Apr 2022 11:05:58 +0800 Message-ID: Date: Thu, 21 Apr 2022 11:05:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH -next v4 1/4] mm: page_table_check: move pxx_user_accessible_page into x86 To: Pasha Tatashin CC: Anshuman Khandual , 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 , , Kefeng Wang , Guohanjun References: <20220418034444.520928-1-tongtiangen@huawei.com> <20220418034444.520928-2-tongtiangen@huawei.com> <1671baf7-046e-7c52-183f-fd654125fd67@arm.com> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 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. Tong. >> >> Thanks, >> Tong. > .