Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
From: Andy Lutomirski
Date: Mon Dec 25 2017 - 09:40:47 EST
On Sat, Dec 23, 2017 at 7:30 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu
> <achirvasub@xxxxxxxxx> wrote:
>>
>> For testing purposes, I've altered machine_kexec_32.c making the
>> following toy commit. It naively undoes part of e802a51, solely to
>> confirm that's where it goes awry in my setup.
>
> That's really funky.
>
> The idt_invalidate() seems to do *exactly* the same thing. It uses
> "load_idt()" on an IDT with size 0, and the supplied address.
>
> Can you disassemble your "set_idt()" code vs the "idt_invalidate()"?
>
>> Is this expected behaviour?
>
> No. The code literally seems identical. The only difference is
>
> (a) where the 0 limit comes from
>
> (b) perhaps build flags and whether it is inlined or not due to being
> in a different file
>
> and neither of those should matter, but maybe they do.
>
> Which is why I'd like you to actually look at the generated code and
> see if you can see any difference..
>
This is presumably the same call-tracing-without-TLS-working problem.
idt_invalidate() is out-of-line and is compiled with full tracing on,
and we're calling it from a context without TLS working (it's
explicitly disabled in load_segments()) in machine_kexec_32.c. The
right fix is probably to inline idt_invalidate() and to add a comment.
Also, why idt_invalidate(phys_to_virt(0))? That makes rather little
sense to me.
--Andy