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 BA39AC433EF for ; Sun, 24 Apr 2022 04:10:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C58A16B0074; Sun, 24 Apr 2022 00:10:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C08626B0075; Sun, 24 Apr 2022 00:10:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA9E16B0078; Sun, 24 Apr 2022 00:10:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 9C0C66B0074 for ; Sun, 24 Apr 2022 00:10:15 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 5AE9581CE1 for ; Sun, 24 Apr 2022 04:10:15 +0000 (UTC) X-FDA: 79390445190.01.6978124 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf21.hostedemail.com (Postfix) with ESMTP id CDD931C003B for ; Sun, 24 Apr 2022 04:10:11 +0000 (UTC) Received: from kwepemi500020.china.huawei.com (unknown [172.30.72.56]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KmF5X0CPwz1JB4m; Sun, 24 Apr 2022 12:09:20 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500020.china.huawei.com (7.221.188.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sun, 24 Apr 2022 12:10:09 +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; Sun, 24 Apr 2022 12:10:08 +0800 Message-ID: Date: Sun, 24 Apr 2022 12:10:07 +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 v5 3/5] mm: page_table_check: add hooks to public helpers To: Anshuman Khandual , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , , "H. Peter Anvin" , Pasha Tatashin , Andrew Morton , Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou CC: , , , , Kefeng Wang , Guohanjun References: <20220421082042.1167967-1-tongtiangen@huawei.com> <20220421082042.1167967-4-tongtiangen@huawei.com> <7fc56f41-a3c2-76be-7a20-dda392f3c4fc@arm.com> From: Tong Tiangen In-Reply-To: <7fc56f41-a3c2-76be-7a20-dda392f3c4fc@arm.com> 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: CDD931C003B X-Stat-Signature: eiazaxnyacmeambh88me3n17epf947ro X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf21.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com X-HE-Tag: 1650773411-462813 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: 在 2022/4/22 14:05, Anshuman Khandual 写道: > > > On 4/21/22 13:50, Tong Tiangen wrote: >> Move ptep_clear() to the include/linux/pgtable.h and add page table check >> relate hooks to some helpers, it's prepare for support page table check >> feature on new architecture. > > Could instrumenting generic page table helpers (fallback instances when its > corresponding __HAVE_ARCH_XXX is not defined on the platform), might add all > the page table check hooks into paths on platforms which have not subscribed > ARCH_SUPPORTS_PAGE_TABLE_CHECK in the first place ? Although these looks have > !CONFIG_PAGE_TABLE_CHECK fallback stubs in the header, hence a build problem > gets avoided. Right, build problems are avoided by fallback stubs in the header file. > >> >> Signed-off-by: Tong Tiangen >> Acked-by: Pasha Tatashin >> --- >> arch/x86/include/asm/pgtable.h | 10 ---------- >> include/linux/pgtable.h | 26 ++++++++++++++++++-------- >> 2 files changed, 18 insertions(+), 18 deletions(-) >> >> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h >> index 564abe42b0f7..51cd39858f81 100644 >> --- a/arch/x86/include/asm/pgtable.h >> +++ b/arch/x86/include/asm/pgtable.h >> @@ -1073,16 +1073,6 @@ static inline pte_t ptep_get_and_clear_full(struct mm_struct *mm, >> return pte; >> } >> >> -#define __HAVE_ARCH_PTEP_CLEAR > > AFICS X86 is the only platform subscribing __HAVE_ARCH_PTEP_CLEAR. Hence if > this is getting dropped for generic ptep_clear(), then no need to add back > #ifnded __HAVE_ARCH_PTEP_CLEAR construct. Generic ptep_clear() is the only > definition for all platforms ? > > Also if this patch is trying to drop off __HAVE_ARCH_PTEP_CLEAR along with > other page table check related changes, it needs to be done via a separate > patch instead. Agreed. IMO, this fix can be patched later. > >> -static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, >> - pte_t *ptep) >> -{ >> - if (IS_ENABLED(CONFIG_PAGE_TABLE_CHECK)) >> - ptep_get_and_clear(mm, addr, ptep); >> - else >> - pte_clear(mm, addr, ptep); >> -} >> - >> #define __HAVE_ARCH_PTEP_SET_WRPROTECT >> static inline void ptep_set_wrprotect(struct mm_struct *mm, >> unsigned long addr, pte_t *ptep) >> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h >> index 49ab8ee2d6d7..10d2d91edf20 100644 >> --- a/include/linux/pgtable.h >> +++ b/include/linux/pgtable.h >> @@ -12,6 +12,7 @@ >> #include >> #include >> #include >> +#include >> >> #if 5 - defined(__PAGETABLE_P4D_FOLDED) - defined(__PAGETABLE_PUD_FOLDED) - \ >> defined(__PAGETABLE_PMD_FOLDED) != CONFIG_PGTABLE_LEVELS >> @@ -272,14 +273,6 @@ static inline bool arch_has_hw_pte_young(void) >> } >> #endif >> >> -#ifndef __HAVE_ARCH_PTEP_CLEAR >> -static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, >> - pte_t *ptep) >> -{ >> - pte_clear(mm, addr, ptep); >> -} >> -#endif >> - >> #ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR >> static inline pte_t ptep_get_and_clear(struct mm_struct *mm, >> unsigned long address, >> @@ -287,10 +280,22 @@ static inline pte_t ptep_get_and_clear(struct mm_struct *mm, >> { >> pte_t pte = *ptep; >> pte_clear(mm, address, ptep); >> + page_table_check_pte_clear(mm, address, pte); >> return pte; >> } >> #endif >> >> +#ifndef __HAVE_ARCH_PTEP_CLEAR >> +static inline void ptep_clear(struct mm_struct *mm, unsigned long addr, >> + pte_t *ptep) >> +{ >> + if (IS_ENABLED(CONFIG_PAGE_TABLE_CHECK)) >> + ptep_get_and_clear(mm, addr, ptep); >> + else >> + pte_clear(mm, addr, ptep); > > Could not this be reworked to avoid IS_ENABLED() ? This is confusing. If the page > table hooks can be added to all potential page table paths via generic helpers, > irrespective of CONFIG_PAGE_TABLE_CHECK option, there is no rationale for doing > a IS_ENABLED() check here. > From the perspective of code logic, we need to check the pte before being cleared. Whether pte check is required depends on IS_ENABLED(). Are there any suggestions for better implementation? Thank you, Tong. >> +} >> +#endif >> + >> #ifndef __HAVE_ARCH_PTEP_GET >> static inline pte_t ptep_get(pte_t *ptep) >> { >> @@ -360,7 +365,10 @@ static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm, >> pmd_t *pmdp) >> { >> pmd_t pmd = *pmdp; >> + >> pmd_clear(pmdp); >> + page_table_check_pmd_clear(mm, address, pmd); >> + >> return pmd; >> } >> #endif /* __HAVE_ARCH_PMDP_HUGE_GET_AND_CLEAR */ >> @@ -372,6 +380,8 @@ static inline pud_t pudp_huge_get_and_clear(struct mm_struct *mm, >> pud_t pud = *pudp; >> >> pud_clear(pudp); >> + page_table_check_pud_clear(mm, address, pud); >> + >> return pud; >> } >> #endif /* __HAVE_ARCH_PUDP_HUGE_GET_AND_CLEAR */ > .