Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 25 Dec 2017 06:40:14 -0800 | Subject | Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot |
| |
On Sat, Dec 23, 2017 at 7:30 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu > <achirvasub@gmail.com> 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
| |