[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <009553ee-8d7b-0b60-8457-f8ac66e27fb4@intel.com>
Date: Tue, 16 Mar 2021 14:16:35 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Kefeng Wang <wangkefeng.wang@...wei.com>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Cc: Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Richard Henderson <rth@...ddle.net>,
Guo Ren <guoren@...nel.org>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Huacai Chen <chenhuacai@...nel.org>,
Jonas Bonn <jonas@...thpole.se>,
Palmer Dabbelt <palmer@...belt.com>,
Heiko Carstens <hca@...ux.ibm.com>,
"David S. Miller" <davem@...emloft.net>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, linux-alpha@...r.kernel.org,
linux-snps-arc@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
linux-hexagon@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-m68k@...ts.linux-m68k.org, linux-mips@...r.kernel.org,
openrisc@...ts.librecores.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-sh@...r.kernel.org,
sparclinux@...r.kernel.org, linux-um@...ts.infradead.org,
linux-xtensa@...ux-xtensa.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm: Move mem_init_print_info() into mm_init()
On 3/16/21 7:26 AM, Kefeng Wang wrote:
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 5430c81eefc9..aa8387aab9c1 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -1350,8 +1350,6 @@ void __init mem_init(void)
> kclist_add(&kcore_vsyscall, (void *)VSYSCALL_ADDR, PAGE_SIZE, KCORE_USER);
>
> preallocate_vmalloc_pages();
> -
> - mem_init_print_info(NULL);
> }
Ignoring any issues with the printk...
Looks harmless enough on x86. The 32-bit code has some cruft in
mem_init() after mem_init_print_info(), so this patch will change the
location of the mem_init_print_info(), but I think it's actually for the
better, since it will be pushed later in boot. As long as the x86
pieces stay the same:
Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
Powered by blists - more mailing lists