[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171125111721.p2o3khstk5tawzqt@gmail.com>
Date: Sat, 25 Nov 2017 12:17:21 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Andy Lutomirski <luto@...capital.net>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Josh Poimboeuf <jpoimboe@...hat.com>
Cc: linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"H . Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping
* Ingo Molnar <mingo@...nel.org> wrote:
> > So it's either unwinder related, or seemingly minor changes to code
> > alignment/placement will make the bug go away.
>
> Ok, I think the Orc unwinder is innocent: I just forced a build with frame
> pointers but with ORC debuginfo and unwinder, and that is booting fine too.
>
> So it's the specific code size and alignment present in the config I sent that is
> triggering the bug. Fudging that alignment/sizing with the workaround patch above
> makes the crash go away.
Ok, after a few hours of debugging with Thomas today we found the bug: it was
caused by Kaiser not mapping the __irqentry_text_start...__irqentry_text_end
kernel virtual memory range, which the IRQ entry code requires before it switches
to the kernel page tables.
This bug was hidden in most configs by virtue of:
kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
__PAGE_KERNEL_RX | _PAGE_GLOBAL);
because the __irqentry_text_start...__irqentry_text_end kernel code section comes
right after this section and is pretty small - so it usually fits into the last
page of the mapping.
But for certain configs the __entry_text_start address crossed the next page
boundary, and was not mapped - resulting in a page fault and then in a double
fault as the entry stack overflowed.
The patch below fixes the crash, and after some testing I'll backmerge it to the
core Kaiser patch in tip:WIP.x86/mm.
There's a few takeaways from this incident though:
- Entry stack overflow debugging is pretty crude and should probably be improved.
- We should better isolate all Kaiser-mapped sections and pad them out
to page boundary. This would immediately trigger any simila false-sharing
side-effect mapping bugs and they wouldn't be .config dependent Heisenbugs.
Thanks,
Ingo
=============>
>From 19bbacd5f7c66b4716716bad97848a9cacd6fe68 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...nel.org>
Date: Sat, 25 Nov 2017 12:10:38 +0100
Subject: [PATCH] x86/mm/kaiser: Fix IRQ entries text section mapping
Backmerge to:
f9e7e52fa076: x86/mm/kaiser: Unmap kernel from userspace page tables (core patch)
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
arch/x86/mm/kaiser.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm/kaiser.c b/arch/x86/mm/kaiser.c
index 1eb27b410556..ea8887bf550a 100644
--- a/arch/x86/mm/kaiser.c
+++ b/arch/x86/mm/kaiser.c
@@ -412,6 +412,8 @@ void __init kaiser_init(void)
kaiser_add_user_map_ptrs_early(__entry_text_start, __entry_text_end,
__PAGE_KERNEL_RX | _PAGE_GLOBAL);
+ kaiser_add_user_map_ptrs_early(__irqentry_text_start, __irqentry_text_end,
+ __PAGE_KERNEL_RX | _PAGE_GLOBAL);
/* the fixed map address of the idt_table */
kaiser_add_user_map_early((void *)idt_descr.address,
Powered by blists - more mailing lists