From: Alexander Tsoy <alexander@tsoy.me>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: "Andy Lutomirski" <luto@amacapital.net>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"Toralf Förster" <toralf.foerster@gmx.de>,
stable <stable@vger.kernel.org>,
"Linux Kernel" <linux-kernel@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: 4.14.9 doesn't boot (regression)
Date: Sun, 31 Dec 2017 01:03:25 +0300 [thread overview]
Message-ID: <20171231010325.6de26fa5@laptop.puleglot.ru> (raw)
In-Reply-To: <20171230175746.5snazk5sem4ribk6@treble>
В Sat, 30 Dec 2017 11:57:46 -0600
Josh Poimboeuf <jpoimboe@redhat.com> пишет:
> On Sat, Dec 30, 2017 at 11:09:46AM -0600, Josh Poimboeuf wrote:
> > On Sat, Dec 30, 2017 at 11:45:13AM +0300, Alexander Tsoy wrote:
> > > В Пт, 29/12/2017 в 21:49 -0600, Josh Poimboeuf пишет:
> > > > On Fri, Dec 29, 2017 at 05:10:35PM -0700, Andy Lutomirski
> > > > wrote:
> > > > > (Also, Josh, the oops code should have printed the contents
> > > > > of the struct pt_regs at the top of the DF stack. Any idea
> > > > > why it didn't?)
> > > >
> > > > Looking at one of the dumps:
> > > >
> > > > [ 392.774879] NMI backtrace for cpu 0
> > > > [ 392.774881] CPU: 0 PID: 1 Comm: init Not tainted
> > > > 4.14.9-gentoo #1
> > > > [ 392.774881] Hardware name: Red Hat KVM, BIOS 0.5.1
> > > > 01/01/2011 [ 392.774882] task: ffff8802368b8000 task.stack:
> > > > ffffc9000000c000 [ 392.774885] RIP: 0010:double_fault+0x0/0x30
> > > > [ 392.774886] RSP: 0000:ffffffffff527fd0 EFLAGS: 00000086
> > > > [ 392.774887] RAX: 000000003fc00000 RBX: 0000000000000001
> > > > RCX: 00000000c0000101
> > > > [ 392.774887] RDX: 00000000ffff8802 RSI: 0000000000000000
> > > > RDI: ffffffffff527f58
> > > > [ 392.774887] RBP: 0000000000000000 R08: 0000000000000000
> > > > R09: 0000000000000000
> > > > [ 392.774888] R10: 0000000000000000 R11: 0000000000000000
> > > > R12: ffffffff816ae726
> > > > [ 392.774888] R13: 0000000000000000 R14: 0000000000000000
> > > > R15: 0000000000000000
> > > > [ 392.774889] FS: 0000000000000000(0000)
> > > > GS:ffff88023fc00000(0000) knlGS:0000000000000000
> > > > [ 392.774889] CS: 0010 DS: 0000 ES: 0000 CR0:
> > > > 0000000080050033 [ 392.774890] CR2: ffffffffff526f08 CR3:
> > > > 0000000235b48002 CR4: 00000000001606f0
> > > > [ 392.774892] Call Trace:
> > > > [ 392.774894] <#DF>
> > > > [ 392.774897] do_double_fault+0xb/0x140
> > > > [ 392.774898] </#DF>
> > > >
> > > > It should have at least printed the #DF iret frame registers,
> > > > which I recently added support for in "x86/unwinder: Handle
> > > > stack overflows more
> > > > gracefully", which is in both 4.14.9 and 4.15-rc5.
> > > >
> > > > I think the missing iret regs are due to a bug in
> > > > show_trace_log_lvl(),
> > > > where if the unwind starts with two regs frames in a row, the
> > > > second regs don't get printed.
> > > >
> > > > Alexander, would you mind reproducing again with the below
> > > > patch? It should still fail, but this time it should hopefully
> > > > show another RIP/RSP/EFLAGS instead of the
> > > > "do_double_fault+0xb/0x140" line.
> > >
> > > Yes, it works:
> > >
> > > [ 23.058064] NMI backtrace for cpu 2
> > > [ 23.058068] CPU: 2 PID: 1 Comm: init Not tainted 4.15.0-rc5+ #1
> > > [ 23.058069] Hardware name: QEMU Standard PC (i440FX + PIIX,
> > > 1996), BIOS 1.10.2-1.fc27 04/01/2014
> > > [ 23.058074] RIP: 0010:double_fault+0x0/0x30
> > > [ 23.058075] RSP: 0000:fffffe800005ffd0 EFLAGS: 00000086
> > > [ 23.058077] RAX: 000000003fd00000 RBX: 0000000000000001 RCX:
> > > 00000000c0000101
> > > [ 23.058077] RDX: 00000000ffff9681 RSI: 0000000000000000 RDI:
> > > fffffe800005ff58
> > > [ 23.058078] RBP: 0000000000000000 R08: 0000000000000000 R09:
> > > 0000000000000000
> > > [ 23.058079] R10: 0000000000000000 R11: 0000000000000000 R12:
> > > ffffffff92001426
> > > [ 23.058080] R13: 0000000000000000 R14: 0000000000000000 R15:
> > > 0000000000000000
> > > [ 23.058083] FS: 0000000000000000(0000)
> > > GS:ffff96813fd00000(0000) knlGS:0000000000000000
> > > [ 23.058084] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > [ 23.058085] CR2: fffffe800005ef08 CR3: 0000000137a09000 CR4:
> > > 00000000000406a0
> > > [ 23.058089] Call Trace:
> > > [ 23.058101] <#DF>
> > > [ 23.058104] RIP: 0010:do_double_fault+0xb/0x140
> > > [ 23.058105] RSP: 0000:fffffe800005ef18 EFLAGS: 00010086
> > > ORIG_RAX: 0000000000000000
> > > [ 23.058106] RAX: 000000003fd00000 RBX: 0000000000000001 RCX:
> > > 00000000c0000101
> > > [ 23.058107] RDX: 00000000ffff9681 RSI: 0000000000000000 RDI:
> > > fffffe800005ff58
> > > [ 23.058107] RBP: 0000000000000000 R08: 0000000000000000 R09:
> > > 0000000000000000
> > > [ 23.058108] R10: 0000000000000000 R11: 0000000000000000 R12:
> > > ffffffff92001426
> > > [ 23.058108] R13: 0000000000000000 R14: 0000000000000000 R15:
> > > 0000000000000000
> > > [ 23.058111] </#DF>
> > > [ 23.058111] Code: 05 00 00 48 89 e7 31 f6 e8 2e 8c 61 ff e9 69
> > > 06 00 00 e8 94 05 00 00 48 89 e7 31 f6 e8 1a 8c 61 ff e9 55 06 00
> > > 00 0f 1f 44 00 00 <0f> 1f 00 48 83 c4 88 e8 e4 04 00 00 48 89 e7
> > > 48 8b 74 24 78 48
> >
> > That's better indeed, though still not quite right. It should have
> > only shown a subset of those registers. One more bug to fix
> > there...
>
> Turns out my previous code to print iret frames was a bit ...
> misguided, to put it nicely. Not sure what I was smoking.
>
> Hopefully the below patch should fix it (in place of the previous
> patch). Would you mind testing again?
>
With that patch I get:
[ 2.160017] NMI backtrace for cpu 0
[ 2.160017] CPU: 0 PID: 1 Comm: init Not tainted 4.15.0-rc5 #1
[ 2.160017] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
[ 2.160017] RIP: 0010:double_fault+0x0/0x30
[ 2.160017] RSP: 0000:fffffe8000007fd0 EFLAGS: 00010086
[ 2.160017] RAX: 00000000ffc00000 RBX: 0000000000000001 RCX: 00000000c0000101
[ 2.160017] RDX: 00000000ffff8edc RSI: 0000000000000000 RDI: fffffe8000007f58
[ 2.160017] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 2.160017] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa3c01426
[ 2.160017] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 2.160017] FS: 0000000000000000(0000) GS:ffff8edcffc00000(0000) knlGS:0000000000000000
[ 2.160017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2.160017] CR2: fffffe8000006f08 CR3: 000000007c153000 CR4: 00000000000006b0
[ 2.160017] Call Trace:
[ 2.160017] <#DF>
[ 2.160017] RIP: 0010:do_double_fault+0xb/0x140
[ 2.160017] RSP: 0000:fffffe8000006f18 EFLAGS: 00010086
[ 2.160017] </#DF>
--
Best regards,
Alexander Tsoy
next prev parent reply other threads:[~2017-12-30 22:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-29 11:14 4.14.9 doesn't boot (regression) Toralf Förster
2017-12-29 13:33 ` Sebastian Gottschall
2017-12-29 13:38 ` Toralf Förster
2017-12-29 15:29 ` Andy Shevchenko
2017-12-29 15:48 ` Alexander Tsoy
2017-12-29 15:52 ` Toralf Förster
2017-12-29 20:12 ` Linus Torvalds
2017-12-29 20:21 ` Ingo Molnar
2017-12-29 21:02 ` Toralf Förster
2017-12-29 21:17 ` Linus Torvalds
2017-12-29 21:39 ` Linus Torvalds
2017-12-29 22:04 ` Alexander Tsoy
2017-12-29 22:30 ` Toralf Förster
2017-12-29 22:53 ` Linus Torvalds
2017-12-29 23:14 ` Toralf Förster
2017-12-30 0:10 ` Andy Lutomirski
2017-12-30 1:00 ` Linus Torvalds
2017-12-30 1:34 ` Linus Torvalds
2017-12-30 9:14 ` Alexander Tsoy
2017-12-30 9:21 ` Toralf Förster
2017-12-30 1:13 ` Alexander Tsoy
2017-12-30 12:58 ` Toralf Förster
2017-12-30 13:14 ` Jiri Kosina
2017-12-30 3:49 ` Josh Poimboeuf
2017-12-30 8:45 ` Alexander Tsoy
2017-12-30 17:09 ` Josh Poimboeuf
2017-12-30 17:57 ` Josh Poimboeuf
2017-12-30 22:03 ` Alexander Tsoy [this message]
2017-12-30 22:16 ` Josh Poimboeuf
2017-12-30 9:30 ` Toralf Förster
2017-12-30 8:32 ` Toralf Förster
2017-12-30 9:53 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171231010325.6de26fa5@laptop.puleglot.ru \
--to=alexander@tsoy.me \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=stable@vger.kernel.org \
--cc=toralf.foerster@gmx.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox