Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933109AbdCUQJH (ORCPT ); Tue, 21 Mar 2017 12:09:07 -0400 Received: from mail-io0-f182.google.com ([209.85.223.182]:36190 "EHLO mail-io0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932941AbdCUQI3 (ORCPT ); Tue, 21 Mar 2017 12:08:29 -0400 MIME-Version: 1.0 In-Reply-To: <20170321015254.GA12487@WeideMacBook-Pro.local> References: <20170320194024.60749-1-thgarnie@google.com> <20170321015254.GA12487@WeideMacBook-Pro.local> From: Thomas Garnier Date: Tue, 21 Mar 2017 09:00:43 -0700 Message-ID: Subject: Re: [PATCH tip v2] x86/mm: Correct fixmap header usage on adaptable MODULES_END To: Wei Yang Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Kees Cook , Andrew Morton , Dave Hansen , Borislav Petkov , Hugh Dickins , Xiao Guangrong , Matthew Wilcox , Boris Ostrovsky , Andy Lutomirski , Paul Gortmaker , Michal Hocko , zijun_hu , Chris Wilson , "the arch/x86 maintainers" , LKML , kasan-dev , Linux-MM , Kernel Hardening Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3884 Lines: 132 On Mon, Mar 20, 2017 at 6:52 PM, Wei Yang wrote: > On Mon, Mar 20, 2017 at 12:40:24PM -0700, Thomas Garnier wrote: >>This patch removes fixmap headers on non-x86 code introduced by the >>adaptable MODULE_END change. It is also removed in the 32-bit pgtable >>header. Instead, it is added by default in the pgtable generic header >>for both architectures. >> >>Signed-off-by: Thomas Garnier >>--- >> arch/x86/include/asm/pgtable.h | 1 + >> arch/x86/include/asm/pgtable_32.h | 1 - >> arch/x86/kernel/module.c | 1 - >> arch/x86/mm/dump_pagetables.c | 1 - >> arch/x86/mm/kasan_init_64.c | 1 - >> mm/vmalloc.c | 4 ---- >> 6 files changed, 1 insertion(+), 8 deletions(-) >> >>diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h >>index 6f6f351e0a81..78d1fc32e947 100644 >>--- a/arch/x86/include/asm/pgtable.h >>+++ b/arch/x86/include/asm/pgtable.h >>@@ -598,6 +598,7 @@ pte_t *populate_extra_pte(unsigned long vaddr); >> #include >> #include >> #include >>+#include >> >> static inline int pte_none(pte_t pte) >> { >>diff --git a/arch/x86/include/asm/pgtable_32.h b/arch/x86/include/asm/pgtable_32.h >>index fbc73360aea0..bfab55675c16 100644 >>--- a/arch/x86/include/asm/pgtable_32.h >>+++ b/arch/x86/include/asm/pgtable_32.h >>@@ -14,7 +14,6 @@ >> */ >> #ifndef __ASSEMBLY__ >> #include >>-#include >> #include >> #include >> > > Yep, I thinks the above two is what I mean. > >>diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c >>index fad61caac75e..477ae806c2fa 100644 >>--- a/arch/x86/kernel/module.c >>+++ b/arch/x86/kernel/module.c >>@@ -35,7 +35,6 @@ >> #include >> #include >> #include >>-#include >> > > Hmm... your code is already merged in upstream? It was merged on tip x86, it was my point before (as Ingo says after too). > > When I look into current Torvalds tree, it looks not include the > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/module.c > > Which tree your change is based on? Do I miss something? tip mm x86, before the first patch. > >> #if 0 >> #define DEBUGP(fmt, ...) \ >>diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c >>index 75efeecc85eb..58b5bee7ea27 100644 >>--- a/arch/x86/mm/dump_pagetables.c >>+++ b/arch/x86/mm/dump_pagetables.c >>@@ -20,7 +20,6 @@ >> >> #include >> #include >>-#include >> > > The same as this one. > >> /* >> * The dumper groups pagetable entries of the same type into one, and for >>diff --git a/arch/x86/mm/kasan_init_64.c b/arch/x86/mm/kasan_init_64.c >>index 1bde19ef86bd..8d63d7a104c3 100644 >>--- a/arch/x86/mm/kasan_init_64.c >>+++ b/arch/x86/mm/kasan_init_64.c >>@@ -9,7 +9,6 @@ >> >> #include >> #include >>-#include >> >> extern pgd_t early_level4_pgt[PTRS_PER_PGD]; >> extern struct range pfn_mapped[E820_X_MAX]; >>diff --git a/mm/vmalloc.c b/mm/vmalloc.c >>index b7d2a23349f4..0dd80222b20b 100644 >>--- a/mm/vmalloc.c >>+++ b/mm/vmalloc.c >>@@ -36,10 +36,6 @@ >> #include >> #include >> >>-#ifdef CONFIG_X86 >>-# include >>-#endif >>- >> #include "internal.h" >> >> struct vfree_deferred { >>-- >>2.12.0.367.g23dc2f6d3c-goog > > > At last, you have tested both on x86-32 and x86-64 platform? I did, I know have a collected set of configs for both 32-bit and 64-bit and a script merging each config and building. It should reduce the risk of exotic configurations not working. > > -- > Wei Yang > Help you, Help me -- Thomas