Displaying 3 results from an estimated 3 matches for "bad_ioapic_register".
2018 Feb 09
0
retpoline mitigation and 6.0
...dl $12, %esp
movl %edi, 12(%esp) # 4-byte Spill
At .Ltmp28 we then call __x86_indirect_thunk which *does* look like
it's doing the right thing (and using the LLVM-emitted thunk instead of
my own behaves the same; I don't think it's my copy-paste at fault).
At .Ltmp29 we call bad_ioapic_register() and then when returns zero (it
does) we je to .LBB0_10 aka .Ltmp34. At which point we happily stomp on
the value of 12(%esp) by spilling something *else* over it:
.LBB0_10: # %if.end28
.Ltmp34:
#DEBUG_VALUE: mp_register_ioapic:address <- $esi
#DEBUG_VALUE: mp_r...
2018 Feb 09
2
retpoline mitigation and 6.0
On Fri, 2018-02-09 at 10:36 +0000, David Woodhouse wrote:
>
> Did you get anywhere with the function attribute? Having isolated the
> next boot failure to "it goes away if I compile io_apic.c without
> retpoline", bisecting it per-function would help to further delay the
> bit where I actually have to start *thinking*...
It's mp_register_ioapic(), and only when
2018 Feb 09
3
retpoline mitigation and 6.0
...%esp) # 4-byte Spill
>
> At .Ltmp28 we then call __x86_indirect_thunk which *does* look like
> it's doing the right thing (and using the LLVM-emitted thunk instead of
> my own behaves the same; I don't think it's my copy-paste at fault).
>
> At .Ltmp29 we call bad_ioapic_register() and then when returns zero (it
> does) we je to .LBB0_10 aka .Ltmp34. At which point we happily stomp on
> the value of 12(%esp) by spilling something *else* over it:
>
> .LBB0_10: # %if.end28
> .Ltmp34:
> #DEBUG_VALUE: mp_register_ioapic:ad...