Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933518AbcLMOfP (ORCPT ); Tue, 13 Dec 2016 09:35:15 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43732 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932452AbcLMOe5 (ORCPT ); Tue, 13 Dec 2016 09:34:57 -0500 Date: Tue, 13 Dec 2016 08:34:55 -0600 From: Josh Poimboeuf To: Borislav Petkov Cc: x86-ml , lkml , Andy Lutomirski Subject: Re: WARNING: kernel stack frame pointer at ffffffff82e03f40 in swapper:0 has bad value (null) Message-ID: <20161213143455.kj5siigmad4f3xim@treble> References: <20161210170444.trpnnq4gtkx5djqm@treble> <20161210172802.gpgjjndo56d43mi4@pd.tnic> <20161212154542.ul6cnzjtkbvooluh@treble> <20161212175023.455mlwhmnqfew2nu@pd.tnic> <20161212181025.uz3gk3jasuskqfmf@treble> <20161212211627.yuodrw35xwq3hmn7@treble> <20161212213446.imd3hpt3nudomu7r@pd.tnic> <20161212221147.twp2nlcolokzq4a4@treble> <20161212223354.qpkut2kc254dfmxi@pd.tnic> <20161212230511.22dusz7bwrvmtjd3@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20161212230511.22dusz7bwrvmtjd3@treble> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 13 Dec 2016 14:34:57 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1088 Lines: 29 On Mon, Dec 12, 2016 at 05:05:11PM -0600, Josh Poimboeuf wrote: > On Mon, Dec 12, 2016 at 11:33:54PM +0100, Borislav Petkov wrote: > > On Mon, Dec 12, 2016 at 04:11:47PM -0600, Josh Poimboeuf wrote: > > > Yes, please. > > > > Attached. > > Thanks, I was able to recreate. Will take a look tomorrow. Figured it out. Your config has CONFIG_PARAVIRT=n, which convinces gcc to create the following preamble for x86_64_start_kernel(): 0000000000000124 : 124: 4c 8d 54 24 08 lea 0x8(%rsp),%r10 129: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp 12d: 41 ff 72 f8 pushq -0x8(%r10) 131: 55 push %rbp 132: 48 89 e5 mov %rsp,%rbp It's an unusual pattern which aligns rsp (though in this case it's already aligned) and saves the start_cpu() return address again on the stack before storing the frame pointer. The unwinder assumes the last stack frame header is at a certain offset, but the above code breaks that assumption. I still need to think about the best way to fix it. -- Josh