lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 02/16] x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
On Mon, Nov 20, 2017 at 05:39:34PM -0800, Andy Lutomirski wrote:
> On Mon, Nov 20, 2017 at 1:55 PM, Josh Poimboeuf <jpoimboe@redhat.com> 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 <jpoimboe@redhat.com> 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] <SYSENTER>
> [ 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] </SYSENTER>

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

\
 
 \ /
  Last update: 2017-11-21 03:29    [W:0.081 / U:9.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site