Displaying 3 results from an estimated 3 matches for "ltmp28".
Did you mean:
ltmp2
2018 Feb 09
0
retpoline mitigation and 6.0
...t *think* I screwed up copying and pasting the retpoline thunk.
So, looking at the retpoline version...
gsi_base is in %edi, and gets spilled to the stack at about .Ltmp22
which is at line 412 right after the printk call:
.Ltmp22:
addl $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 ....
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
...t; So, looking at the retpoline version...
>
> gsi_base is in %edi, and gets spilled to the stack at about .Ltmp22
> which is at line 412 right after the printk call:
>
> .Ltmp22:
> addl $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 (...