From: Josh Poimboeuf <jpoimboe@redhat.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Pavel Machek <pavel@ucw.cz>,
kernel list <linux-kernel@vger.kernel.org>,
mingo@kernel.org, luto@kernel.org, bp@alien8.de,
brgerst@gmail.com, dvlasenk@redhat.com,
torvalds@linux-foundation.org, peterz@infradead.org,
tglx@linutronix.de
Subject: Re: v4.10: kernel stack frame pointer .. has bad value (null)
Date: Wed, 22 Feb 2017 15:15:21 -0600 [thread overview]
Message-ID: <20170222211521.bmhh74huuyfvr6dz@treble> (raw)
In-Reply-To: <a38ce0ab-ec12-2871-e005-08170fcd5c9b@zytor.com>
On Wed, Feb 22, 2017 at 12:51:11PM -0800, H. Peter Anvin wrote:
> On 02/22/17 08:45, Josh Poimboeuf wrote:
> >>
> >> FWIW, it would be really darned nice to not have all those zeroes in a
> >> 32-bit stack frame dump.
> >
> > Yeah, I'll fix that.
> >
> >> Is not a zero stack frame pointer value an end of stack token?
> >
> > There's no end of stack "token" per se, though any frame pointer value
> > outside the bounds of the stack will terminate the stack trace (and that
> > still happened here).
> >
>
> Well, my understanding is that at least gdb and perhaps other unwinders
> consider a zero stack frame pointer to be an indicator that the stack
> has reached its end. That's why I'm wondering if this is possible in
> this case or if it is unlikely because of the value.
I'm not sure I follow your question. The frame pointer was zero, and
that did cause the unwinder to stop the stack trace. The warning was
because it ended in an unexpected place.
> > The warning is because the stack trace didn't make it all the way to the
> > "end" location of the stack (right before the syscall pt_regs location).
> > The warning is part of the effort to ensure reliable stacks.
>
> It would be useful to get an understanding why...
Agreed...
--
Josh
next prev parent reply other threads:[~2017-02-22 21:15 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 22:14 Pavel Machek
2017-02-21 23:12 ` Josh Poimboeuf
2017-02-21 23:15 ` H. Peter Anvin
2017-02-22 16:45 ` Josh Poimboeuf
2017-02-22 20:51 ` H. Peter Anvin
2017-02-22 21:15 ` Josh Poimboeuf [this message]
2017-02-22 21:05 ` Pavel Machek
2017-02-22 21:21 ` Josh Poimboeuf
2017-02-22 22:47 ` Pavel Machek
2017-02-22 22:56 ` Josh Poimboeuf
2017-02-22 23:18 ` Josh Poimboeuf
2017-02-23 20:10 ` Pavel Machek
2017-02-25 5:04 ` Josh Poimboeuf
2017-03-02 23:45 ` Josh Poimboeuf
2017-03-06 16:38 ` Pavel Machek
2017-03-07 17:38 ` Josh Poimboeuf
2017-03-07 17:52 ` Linus Torvalds
2017-03-07 17:59 ` Andy Lutomirski
2017-03-07 18:28 ` Josh Poimboeuf
2017-03-07 18:30 ` Josh Poimboeuf
2017-03-07 18:40 ` Linus Torvalds
2017-03-08 17:37 ` Josh Poimboeuf
2017-03-08 18:25 ` Linus Torvalds
2017-03-08 18:54 ` Andy Lutomirski
2017-03-08 21:22 ` Pavel Machek
2017-03-09 9:38 ` Geert Uytterhoeven
2017-03-09 10:56 ` Pavel Machek
2017-03-09 12:16 ` Geert Uytterhoeven
2017-03-10 13:17 ` Compiling kernels faster (was Re: v4.10: kernel stack frame pointer .. has bad value (null)) Pavel Machek
2017-03-10 13:28 ` Geert Uytterhoeven
2017-03-10 14:15 ` Willy Tarreau
2017-03-09 10:49 ` Old compiler versions " Pavel Machek
2017-03-09 18:05 ` Linus Torvalds
2017-03-09 15:29 ` v4.10: kernel stack frame pointer .. has bad value (null) Peter Zijlstra
2017-03-09 21:12 ` Pavel Machek
2017-03-08 21:29 ` Josh Poimboeuf
2017-03-09 14:14 ` Steven Rostedt
2017-03-09 18:31 ` Josh Poimboeuf
2017-03-16 15:42 ` [PATCH] x86: mostly disable '-maccumulate-outgoing-args' Josh Poimboeuf
2017-03-16 17:32 ` Steven Rostedt
2017-03-16 18:36 ` Josh Poimboeuf
2017-03-16 18:53 ` Josh Poimboeuf
2017-03-16 19:04 ` Josh Poimboeuf
2017-03-16 19:07 ` Steven Rostedt
2017-03-16 19:06 ` Steven Rostedt
2017-03-16 19:31 ` [PATCH v2] " Josh Poimboeuf
2017-03-22 7:51 ` Ingo Molnar
2017-03-22 15:48 ` Josh Poimboeuf
2017-03-28 8:13 ` [tip:x86/urgent] x86/build: Mostly " tip-bot for Josh Poimboeuf
2017-03-28 16:17 ` Josh Poimboeuf
2017-03-30 9:58 ` tip-bot for Josh Poimboeuf
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=20170222211521.bmhh74huuyfvr6dz@treble \
--to=jpoimboe@redhat.com \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=pavel@ucw.cz \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®