[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy9r2GAFenswm92sdz0qnbazPcofm668JqYrxEVFALfZA@mail.gmail.com>
Date: Wed, 4 Oct 2017 14:30:42 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Wu Fengguang <fengguang.wu@...el.com>,
Byungchul Park <byungchul.park@....com>,
Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
LKP <lkp@...org>, Borislav Petkov <bp@...en8.de>,
"the arch/x86 maintainers" <x86@...nel.org>,
Peter Anvin <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer
dereference at 000001f2
On Wed, Oct 4, 2017 at 2:06 PM, Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> I compiled the same kernel with a similar version of GCC. It turns out
> that GCC *does* create unaligned stacks with frame pointers enabled:
Christ. What a piece of crap.
It doesn't even seem to make any sense. Spill room for the "u16
item_count" and "u8 move_type"?
That function is disgusting anyway (the switch really should be
outside the loop, not inside it), but whatever. No excuse for that
kind of garbage code generation.
> This was a leaf function. For no apparent reason, GCC 4.8 decided to
> subtract 3 from the stack pointer in the prologue.
Can you make objtool warn about unaligned stack pointer additions like that?
Maybe it only happens in very limited cases, and we can find a pattern
to why gcc generates garbage code like that? And perhaps even how to
just avoid it?
Linus
Powered by blists - more mailing lists