From: Feng Tang <feng.tang@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Michal Hocko <mhocko@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Ingo Molnar <mingo@elte.hu>,
"H . Peter Anvin" <hpa@linux.intel.com>,
Yinghai Lu <yinghai@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for NO_BOOTMEM
Date: Fri, 31 Aug 2018 14:15:19 +0800 [thread overview]
Message-ID: <20180831061519.3zbxsjs4rd6mmsuo@shbuild888> (raw)
In-Reply-To: <alpine.DEB.2.21.1808301523510.1210@nanos.tec.linutronix.de>
On Thu, Aug 30, 2018 at 03:25:42PM +0200, Thomas Gleixner wrote:
> And where is the problem? We know that we need the fixmap during early boot
> anyway, so allocating the PTE page statically and setting it up early
> enough is not really rocket science. No allocator required.
Further check shows the page table for fixmap is already setup in [-12M, -10M],
but fixmap's address space breaks the expection under certain kernel config.
So here is another fix, please review, thanks!
----------------------------------------------------------------
From f63e4e5c6166a2f8d13ad3142b7a49b2fd1f8edf Mon Sep 17 00:00:00 2001
From: Feng Tang <feng.tang@intel.com>
Date: Fri, 31 Aug 2018 13:48:21 +0800
Subject: [PATCH] x86, mm: Make the real fixmap address consistent
We hit a kernel panic when enabling earlycon for a platform, the
call trace is:
panic+0xd2/0x220
__alloc_bootmem+0x31/0x34
spp_getpage+0x60/0x8a
fill_pte+0x71/0x130
__set_pte_vaddr+0x1d/0x50
set_pte_vaddr+0x3c/0x60
__native_set_fixmap+0x23/0x30
native_set_fixmap+0x30/0x40
setup_earlycon+0x1e0/0x32f
param_setup_earlycon+0x13/0x22
do_early_param+0x5b/0x90
parse_args+0x1f7/0x300
parse_early_options+0x24/0x28
parse_early_param+0x65/0x73
setup_arch+0x31e/0x9f1
start_kernel+0x58/0x44e
This panic happens as the earlycon's fixmap address has no
pmd/pte ready, and __set_fixmap will try to allocate memory to
setup the page table, and trigger panic due to no memory.
x86 kernel actually prepares the page table for fixmap in head_64.S:
NEXT_PAGE(level2_fixmap_pgt)
.fill 506,8,0
.quad level1_fixmap_pgt - __START_KERNEL_map + _PAGE_TABLE_NOENC
/* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */
.fill 5,8,0
and it expects the fixmap address is in [-12M, -10M] range, but
current code in fixmap.h will break the expectation when
X86_VSYSCALL_EMULATION=n
#ifdef CONFIG_X86_VSYSCALL_EMULATION
VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT,
#endif
So removing the "#ifdef" will make the fixmap address space stable in
[-12M, -10M] and fix the issue.
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
arch/x86/include/asm/fixmap.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index e203169931c7..fcf27171f493 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -67,9 +67,7 @@ enum fixed_addresses {
#ifdef CONFIG_X86_32
FIX_HOLE,
#else
-#ifdef CONFIG_X86_VSYSCALL_EMULATION
VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT,
-#endif
#endif
FIX_DBGP_BASE,
FIX_EARLYCON_MEM_BASE,
--
2.14.1
next prev parent reply other threads:[~2018-08-31 6:11 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 9:03 Feng Tang
2018-08-30 10:44 ` Peter Zijlstra
2018-08-30 11:12 ` Michal Hocko
2018-08-30 11:54 ` Thomas Gleixner
2018-08-30 12:49 ` Michal Hocko
2018-08-30 12:59 ` Feng Tang
2018-08-30 13:05 ` Thomas Gleixner
2018-08-30 13:19 ` Feng Tang
2018-08-30 13:25 ` Thomas Gleixner
2018-08-30 13:55 ` Feng Tang
2018-08-31 6:15 ` Feng Tang [this message]
2018-08-31 11:33 ` Thomas Gleixner
2018-08-31 13:36 ` Feng Tang
2018-09-07 8:17 ` Feng Tang
2018-09-07 10:52 ` Thomas Gleixner
2018-09-10 9:39 ` Feng Tang
2018-09-10 9:53 ` Thomas Gleixner
2018-09-11 6:14 ` Feng Tang
2018-09-15 10:29 ` Thomas Gleixner
2018-09-15 16:47 ` Feng Tang
2018-09-15 17:28 ` Thomas Gleixner
2018-09-16 14:35 ` Feng Tang
2018-09-16 14:43 ` Thomas Gleixner
2018-09-16 15:06 ` Feng Tang
2018-09-17 7:01 ` Feng Tang
2018-09-17 7:01 ` Thomas Gleixner
2018-08-30 12:09 ` Peter Zijlstra
2018-08-30 12:39 ` Michal Hocko
2018-08-30 12:43 ` Feng Tang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180831061519.3zbxsjs4rd6mmsuo@shbuild888 \
--to=feng.tang@intel.com \
--cc=ak@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®