[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171229091741.GC18441@kroah.com>
Date: Fri, 29 Dec 2017 10:17:41 +0100
From: Greg KH <greg@...ah.com>
To: Alexander Tsoy <alexander@...y.me>,
Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>
Cc: Borislav Petkov <bp@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Borislav Petkov <bp@...en8.de>,
Borislav Petkov <bpetkov@...e.de>,
Brian Gerst <brgerst@...il.com>,
Dave Hansen <dave.hansen@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Laight <David.Laight@...lab.com>,
Denys Vlasenko <dvlasenk@...hat.com>,
Eduardo Valentin <eduval@...zon.com>,
Greg KH <gregkh@...uxfoundation.org>,
"H. Peter Anvin" <hpa@...or.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Juergen Gross <jgross@...e.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Rik van Riel <riel@...hat.com>,
Will Deacon <will.deacon@....com>, aliguori@...zon.com,
daniel.gruss@...k.tugraz.at, hughd@...gle.com, keescook@...gle.com,
Kernel Mailing List <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>
Subject: Re: 4.14.9 with CONFIG_MCORE2 fails to boot
On Thu, Dec 28, 2017 at 12:33:22PM +0300, Alexander Tsoy wrote:
> Hello,
>
> 4.14.9 fails to boot if CONFIG_MCORE2 is enabled and when compiled with
> gcc 6+. More details in the following bug reports:
> https://bugzilla.kernel.org/show_bug.cgi?id=198263
> https://bugs.gentoo.org/642268
>
> I bisected it to the commit below:
>
> $ git bisect good
> 2bc9fa0beaf10206a778f02e9e5cb62f50345b1a is the first bad commit
> commit 2bc9fa0beaf10206a778f02e9e5cb62f50345b1a
> Author: Andy Lutomirski <luto@...nel.org>
> Date: Mon Dec 4 15:07:23 2017 +0100
>
> x86/entry/64: Use a per-CPU trampoline stack for IDT entries
>
> commit 7f2590a110b837af5679d08fc25c6227c5a8c497 upstream.
>
> Historically, IDT entries from usermode have always gone directly
> to the running task's kernel stack. Rearrange it so that we enter
> on
> a per-CPU trampoline stack and then manually switch to the task's
> stack.
> This touches a couple of extra cachelines, but it gives us a chance
> to run some code before we touch the kernel stack.
>
> The asm isn't exactly beautiful, but I think that fully refactoring
> it can wait.
>
> Signed-off-by: Andy Lutomirski <luto@...nel.org>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Reviewed-by: Borislav Petkov <bp@...e.de>
> Reviewed-by: Thomas Gleixner <tglx@...utronix.de>
> Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Borislav Petkov <bpetkov@...e.de>
> Cc: Brian Gerst <brgerst@...il.com>
> Cc: Dave Hansen <dave.hansen@...el.com>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: David Laight <David.Laight@...lab.com>
> Cc: Denys Vlasenko <dvlasenk@...hat.com>
> Cc: Eduardo Valentin <eduval@...zon.com>
> Cc: Greg KH <gregkh@...uxfoundation.org>
> Cc: H. Peter Anvin <hpa@...or.com>
> Cc: Josh Poimboeuf <jpoimboe@...hat.com>
> Cc: Juergen Gross <jgross@...e.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Rik van Riel <riel@...hat.com>
> Cc: Will Deacon <will.deacon@....com>
> Cc: aliguori@...zon.com
> Cc: daniel.gruss@...k.tugraz.at
> Cc: hughd@...gle.com
> Cc: keescook@...gle.com
> Link: https://lkml.kernel.org/r/20171204150606.225330557@linutronix
> .de
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>
> :040000 040000 275d4746936a9e521a2b5041856f7dc1d1820dc6
> 8f8e869fd59c3dd781dceffa76e53e41d733a0cf M arch
>
> $ git bisect log
> git bisect start
> # bad: [dad5c1402c570cd07a80113784bc20a7f930c8ae] Linux 4.14.9
> git bisect bad dad5c1402c570cd07a80113784bc20a7f930c8ae
> # good: [7b3775017f4e6b87dfd2c7f63d1eaf057948f31d] Linux 4.14.8
> git bisect good 7b3775017f4e6b87dfd2c7f63d1eaf057948f31d
> # good: [d120cd749ef9770ee98b708a83b49547dcf1c0e1] x86/entry/64:
> Separate cpu_current_top_of_stack from TSS.sp0
> git bisect good d120cd749ef9770ee98b708a83b49547dcf1c0e1
> # bad: [97f41b41c432e5a80c91445d92c2f4b729984d36] powerpc/xmon: Avoid
> tripping SMP hardlockup watchdog
> git bisect bad 97f41b41c432e5a80c91445d92c2f4b729984d36
> # bad: [bfd66a406fe7e590055c1d6714adc697f18664c8] PCI: Avoid bus reset
> if bridge itself is broken
> git bisect bad bfd66a406fe7e590055c1d6714adc697f18664c8
> # bad: [8388d287e361a2fd0a39bece30a736d692d5c3d8] x86/cpufeatures: Make
> CPU bugs sticky
> git bisect bad 8388d287e361a2fd0a39bece30a736d692d5c3d8
> # bad: [bb568391775d4a840992e2d2493f39d6e86401e3] x86/entry/64: Move
> the IST stacks into struct cpu_entry_area
> git bisect bad bb568391775d4a840992e2d2493f39d6e86401e3
> # bad: [2bc9fa0beaf10206a778f02e9e5cb62f50345b1a] x86/entry/64: Use a
> per-CPU trampoline stack for IDT entries
> git bisect bad 2bc9fa0beaf10206a778f02e9e5cb62f50345b1a
> # good: [c3dbef1bd0f7eb09daf49409ea533aa1b0eeb82e] x86/espfix/64: Stop
> assuming that pt_regs is on the entry stack
> git bisect good c3dbef1bd0f7eb09daf49409ea533aa1b0eeb82e
> # first bad commit: [2bc9fa0beaf10206a778f02e9e5cb62f50345b1a]
> x86/entry/64: Use a per-CPU trampoline stack for IDT entries
Thanks for letting us know. Does Linus's current tree also have this
same problem for you?
greg k-h
Powered by blists - more mailing lists