From: Linus Torvalds <torvalds@linux-foundation.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Michel Dänzer" <michel@daenzer.net>,
"Jakub Jelinek" <jakub@redhat.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Debian GCC Maintainers" <debian-gcc@lists.debian.org>,
"Debian Kernel Team" <debian-kernel@lists.debian.org>
Subject: Re: Random panic in load_balance() with 3.16-rc
Date: Fri, 25 Jul 2014 13:01:11 -0700 [thread overview]
Message-ID: <CA+55aFxbWfYPuzCZvhy24zVfWwhN=DcxrCDguZ74cfsOz9U7PQ@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFzOoJzqJ=4RVPEBfscA8oRdr5Nv7fKx9aXYw2+frkuhwA@mail.gmail.com>
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Some simple pattern to make sure that the "sub $frame-size,%rsp" comes
> before any accesses to (%rbp) (when frame pointers are enabled)
> *might* work, but it might also end up missing things.
You're going to have a hard time doing that pattern. Just for fun, I
did something really quick in awk:
/>:/ { state = 0 }
/%rsp,%rbp/ { state = 1 }
/\$.*rsp/ { state = 2 }
/lea/ { next }
/\(%rbp\)/ { if (state == 1) print "Error: " $0; state = 2; }
which is incomprehensible line noise, but it's a trivial state machine
where "beginning of function" starts state 0, "mov %rsp,%rbp" starts
state 1 ("have frame pointer in function"), sub/add constant of %rsp
starts state 2 ("created frame"), and then we ignore "lea" (because we
don't follow address calculations off %rbp) and error out if we see an
access through %rbp in a function with a frame pointer but without a
frame created.
That thing is excessively stupid, in other words, but hey, it's good
to see "ok, what does that tell us".
And what it tells me is that gcc does some crazy things.
For example, gcc will not create a small stack frame with "sub
$8,%rsp". No, what gcc does is to use a random "push" instruction.
Fair enough, but that really makes things much harder to see. Here's
an example:
ffffffff813143a3 <dock_notify>:
ffffffff813143a3: 55 push %rbp
ffffffff813143a4: 48 89 e5 mov %rsp,%rbp
ffffffff813143a7: 41 57 push %r15
ffffffff813143a9: 41 56 push %r14
ffffffff813143ab: 49 89 fe mov %rdi,%r14
ffffffff813143ae: 41 55 push %r13
ffffffff813143b0: 41 89 f5 mov %esi,%r13d
ffffffff813143b3: 41 54 push %r12
ffffffff813143b5: 53 push %rbx
ffffffff813143b6: 51 push %rcx
...
ffffffff81314501: 48 8b 7e 08 mov 0x8(%rsi),%rdi
ffffffff81314505: 48 89 75 d0 mov %rsi,-0x30(%rbp)
ffffffff81314509: e8 5f d1 ff ff callq
ffffffff8131166d <acpi_bus_scan>
ffffffff8131450e: 85 c0 test %eax,%eax
...
ffffffff813145d6: 5a pop %rdx
ffffffff813145d7: 5b pop %rbx
ffffffff813145d8: 44 89 e0 mov %r12d,%eax
ffffffff813145db: 41 5c pop %r12
ffffffff813145dd: 41 5d pop %r13
ffffffff813145df: 41 5e pop %r14
ffffffff813145e1: 41 5f pop %r15
ffffffff813145e3: 5d pop %rbp
ffffffff813145e4: c3 retq
note the use (deep down in the function) of -0x30(%rbp), and note how
it does "pop %rdx" twice to undo the "push %rcx". It was just to
allocate space.
So you definitely have to track the actual stack pointer updates, not
just the patterns of add/sub to %rsp.
Linus
next prev parent reply other threads:[~2014-07-25 20:01 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53C77BB8.6030804@daenzer.net>
2014-07-17 7:58 ` Random panic in load_balance() with 3.16-rc Peter Zijlstra
2014-07-18 9:29 ` Michel Dänzer
2014-07-22 6:13 ` Michel Dänzer
2014-07-23 3:53 ` Michel Dänzer
2014-07-23 4:21 ` Linus Torvalds
2014-07-23 6:49 ` Peter Zijlstra
2014-07-23 8:05 ` Michel Dänzer
2014-07-23 8:28 ` Peter Zijlstra
2014-07-23 9:25 ` Peter Zijlstra
2014-07-23 9:31 ` Michel Dänzer
2014-07-23 9:45 ` Dietmar Eggemann
2014-07-23 11:11 ` Peter Zijlstra
2014-07-23 11:30 ` Peter Zijlstra
2014-07-23 14:24 ` Peter Zijlstra
2014-07-23 14:38 ` Michel Dänzer
2014-07-23 15:51 ` Linus Torvalds
[not found] ` <20140723155526.GW3935@laptop>
2014-07-23 16:54 ` Linus Torvalds
2014-07-23 17:03 ` Peter Zijlstra
2014-07-23 17:12 ` Linus Torvalds
2014-07-23 17:26 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:35 ` Linus Torvalds
2014-07-23 18:41 ` Peter Zijlstra
2014-07-23 18:55 ` Linus Torvalds
2014-07-23 19:02 ` Peter Zijlstra
2014-07-23 19:20 ` Linus Torvalds
2014-07-24 1:43 ` Michel Dänzer
2014-07-24 18:47 ` Linus Torvalds
2014-07-24 18:59 ` Peter Zijlstra
2014-07-25 1:25 ` Michel Dänzer
2014-07-25 2:33 ` Linus Torvalds
2014-07-25 2:50 ` Nick Krause
2014-07-25 2:36 ` Nick Krause
2014-07-25 3:55 ` Alexei Starovoitov
2014-07-25 4:00 ` Nick Krause
2014-07-25 14:02 ` Steven Rostedt
2014-07-25 18:29 ` Linus Torvalds
2014-07-25 19:10 ` Steven Rostedt
2014-07-25 20:01 ` Linus Torvalds [this message]
2014-07-25 20:13 ` Steven Rostedt
2014-07-25 21:25 ` Jakub Jelinek
2014-07-26 18:28 ` Linus Torvalds
2014-07-26 18:39 ` Linus Torvalds
2014-07-26 19:35 ` Markus Trippelsdorf
2014-07-26 19:55 ` Theodore Ts'o
2014-07-26 20:20 ` Markus Trippelsdorf
2014-07-26 22:08 ` Jakub Jelinek
2014-07-26 19:56 ` Linus Torvalds
2014-07-26 20:03 ` Linus Torvalds
2014-07-26 20:19 ` Markus Trippelsdorf
2014-07-26 20:39 ` Linus Torvalds
2014-07-28 12:26 ` Frank Ch. Eigler
2014-07-28 13:10 ` Theodore Ts'o
2014-07-28 14:11 ` Frank Ch. Eigler
2014-07-28 16:45 ` Linus Torvalds
2014-07-28 17:27 ` Alexei Starovoitov
2014-07-28 18:09 ` Markus Trippelsdorf
2014-07-28 18:28 ` Linus Torvalds
2014-07-28 18:41 ` Markus Trippelsdorf
2014-07-29 8:58 ` Jakub Jelinek
2014-07-28 19:50 ` Theodore Ts'o
2014-07-28 3:47 ` Michel Dänzer
2014-07-28 16:48 ` Linus Torvalds
2014-07-29 2:29 ` Michel Dänzer
2014-08-05 3:19 ` Steven Rostedt
2014-07-26 18:02 ` Steven Chamberlain
2014-07-29 9:20 ` Michel Dänzer
2014-07-25 6:48 ` Jakub Jelinek
2014-07-25 8:15 ` Linus Torvalds
2014-07-25 9:03 ` Michel Dänzer
2014-07-25 9:21 ` Markus Trippelsdorf
2014-07-25 9:42 ` Markus Trippelsdorf
2014-07-23 18:07 ` Linus Torvalds
2014-07-23 18:31 ` Peter Zijlstra
2014-07-23 18:24 ` Peter Zijlstra
2014-07-23 17:04 ` Peter Zijlstra
2014-07-23 17:15 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:23 ` Peter Zijlstra
2014-07-23 10:52 ` Peter Zijlstra
2014-07-24 7:18 ` Michel Dänzer
2014-07-24 7:51 ` Peter Zijlstra
2014-07-24 9:55 ` Peter Zijlstra
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='CA+55aFxbWfYPuzCZvhy24zVfWwhN=DcxrCDguZ74cfsOz9U7PQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=ast@kernel.org \
--cc=debian-gcc@lists.debian.org \
--cc=debian-kernel@lists.debian.org \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).