On Fri, Jul 28, 2017 at 07:59:12PM +0000, Levin, Alexander (Sasha Levin) wrote:
> On Fri, Jul 28, 2017 at 01:57:20PM -0500, Josh Poimboeuf wrote:
> >Thanks, that's much better. I'm relieved the unwinder didn't screw that
> >up, at least.
> >
> >This looks like a tricky one. Is it easily recreatable?
>
> Yeah, I just hit it again with slightly different initial calls:
Sasha sent me some data privately. As I suspected, the cause is some
bad ORC data. Objtool incorrectly assumes that once the frame pointer
is set up, it no longer gets touched.
For example:
ffffffff81820680 <pipe_wait>:
ffffffff81820680: 41 56 push %r14
ffffffff81820682: 41 55 push %r13
ffffffff81820684: 41 54 push %r12
ffffffff81820686: 49 89 fc mov %rdi,%r12
ffffffff81820689: 55 push %rbp
ffffffff8182068a: 53 push %rbx
ffffffff8182068b: 48 bb 00 00 00 00 00 movabs
$0xdffffc0000000000,%rbx
ffffffff81820692: fc ff df
ffffffff81820695: 48 83 c4 80 add
$0xffffffffffffff80,%rsp
ffffffff81820699: 48 89 e5 mov %rsp,%rbp
ffffffff8182069c: 48 c7 04 24 b3 8a b5 movq $0x41b58ab3,(%rsp)
ffffffff818206a3: 41
ffffffff818206a4: 48 c7 44 24 08 07 a5 movq
$0xffffffff8621a507,0x8(%rsp)
ffffffff818206ab: 21 86
ffffffff818206a9: R_X86_64_32S .rodata+0xa1a507
ffffffff818206ad: 48 c1 ed 03 shr $0x3,%rbp
In this case, rbp was pushed ("push %rbp") and then replaced with rsp
("mov %rsp, %rbp"), which is the normal frame pointer setup. But then
rbp was modified ("shr 0x3, %rbp"), which objtool didn't expect.
Objtool will need to be made smarter here somehow. I'll be on vacation
next week so it might be a week or so before I can come up with the fix.
Despite the scary KASAN warning, this is only a minor bug. The ORC data
isn't perfect yet, so these types of issues will happen until we get the
kinks worked out. The good news is the unwinder recovered from the bad
ORC data gracefully, and the oops dump still showed the rest of the
addresses (with question marks).
--
Josh
