From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752405AbdKUC3k (ORCPT ); Mon, 20 Nov 2017 21:29:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53034 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751876AbdKUC3j (ORCPT ); Mon, 20 Nov 2017 21:29:39 -0500 Date: Mon, 20 Nov 2017 20:29:37 -0600 From: Josh Poimboeuf To: Andy Lutomirski Cc: X86 ML , Borislav Petkov , "linux-kernel@vger.kernel.org" , Brian Gerst , Dave Hansen , Linus Torvalds Subject: Re: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack Message-ID: <20171121022937.3xitb5idtewhhja7@treble> References: <01c7223352405fe6d55d1ea7c0ff1d7282c30cc7.1511195781.git.luto@kernel.org> <20171120204212.6rlbhh4btxqnjanm@treble> <20171120210050.mq6hrzomvrd7kuaf@treble> <20171120212738.rdevfne2vrruyvt4@treble> <20171120215550.2yiukhcnts5g77ho@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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.30]); Tue, 21 Nov 2017 02:29:39 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 20, 2017 at 05:39:34PM -0800, Andy Lutomirski wrote: > On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf wrote: > > On Mon, Nov 20, 2017 at 01:30:12PM -0800, Andy Lutomirski wrote: > >> On Mon, Nov 20, 2017 at 1:27 PM, Josh Poimboeuf wrote: > >> > On Mon, Nov 20, 2017 at 01:07:16PM -0800, Andy Lutomirski wrote: > >> >> >> but, more importantly, the OOPS unwinder will just bail without this > >> >> >> patch. With the patch, we get a valid unwind, except that everything > >> >> >> has a ? in front. > >> >> > > >> >> > Hm. I can't even fathom how that's possible. Are you talking about the > >> >> > "unwind from NMI to SYSENTER stack" path? Or any unwind to a syscall? > >> >> > Either way I'm baffled... If the unwinder only encounters the SYSENTER > >> >> > stack at the end, how could that cause everything beforehand to have a > >> >> > question mark? > >> >> > >> >> I mean that, if I put a ud2 or other bug in the code that runs on the > >> >> SYSENTER stack, without this patch, I get a totally blank call trace. > >> > > >> > I would expect a blank call trace either way... > >> > >> Try making sync_regs use a few kB of stack space or, better yet, call > >> a non-inlined function that uses too much stack. > > > > You mean overflow the exception stack? I still don't see how that would > > do it. > > > > If you could show a specific example, with splats from before/after, > > that would be helpful. Because I still have no idea how this patch > > could possibly help. > > I added BUG() to sync_regs(). With the patch, I get: > > [ 4.211553] PANIC: double fault, error_code: 0x0 > [ 4.212113] CPU: 0 PID: 1 Comm: sh Not tainted 4.14.0+ #920 > [ 4.212741] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), > BIOS 1.10.2-1.fc26 04/01/2014 > [ 4.213536] task: ffff88001aa18000 task.stack: ffff88001aa20000 > [ 4.214059] RIP: 0010:do_error_trap+0x33/0x1c0 > [ 4.214449] RSP: 0000:ffffffffff1b8f78 EFLAGS: 00010096 > [ 4.214934] RAX: dffffc0000000000 RBX: ffffffffff1b8f90 RCX: 0000000000000006 > [ 4.215554] RDX: ffffffff82048b20 RSI: 0000000000000000 RDI: ffffffffff1b9110 > [ 4.216176] RBP: ffffffffff1b9088 R08: 0000000000000004 R09: 0000000000000000 > [ 4.216793] R10: 0000000000000000 R11: fffffbffffe3723f R12: 0000000000000006 > [ 4.217419] R13: 0000000000000000 R14: 0000000000000004 R15: 0000000000000000 > [ 4.218046] FS: 0000000000000000(0000) GS:ffff88001ae00000(0000) > knlGS:0000000000000000 > [ 4.218775] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 4.219280] CR2: ffffffffff1b8f68 CR3: 00000000193da002 CR4: 00000000003606f0 > [ 4.219931] Call Trace: > [ 4.220156] > [ 4.220383] ? async_page_fault+0x36/0x60 > [ 4.220768] ? invalid_op+0x22/0x40 > [ 4.221087] ? async_page_fault+0x36/0x60 > [ 4.221442] ? sync_regs+0x3c/0x40 > [ 4.221745] ? sync_regs+0x2e/0x40 > [ 4.222051] ? error_entry+0x6c/0xd0 > [ 4.222395] ? async_page_fault+0x36/0x60 > [ 4.222748] Ah, page fault. I thought you were talking about an NMI. I get it now. Did it overflow the stack? I think that would explain the question marks. -- Josh