Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751570AbdLXH1C (ORCPT ); Sun, 24 Dec 2017 02:27:02 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:35634 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbdLXH1A (ORCPT ); Sun, 24 Dec 2017 02:27:00 -0500 X-Google-Smtp-Source: ACJfBovYYalrTucXD+kwJr8k2j+OYAazbpMze3UcxNimBihId+7+KbmJXUgqgMIN5BGnzKikI3aUQQ== Date: Sun, 24 Dec 2017 02:28:32 -0500 From: Alexandru Chirvasitu To: Linus Torvalds Cc: Thomas Gleixner , kernel list , Andy Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Ingo Molnar Subject: Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot Message-ID: <20171224072832.GA959@chirva-void> References: <20171224014415.GA5663@chirva-void> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3918 Lines: 102 Thank you for the swift reply! On Sat, Dec 23, 2017 at 07:30:21PM -0800, Linus Torvalds wrote: > On Sat, Dec 23, 2017 at 5:44 PM, Alexandru Chirvasitu > 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()"? > I seem to have done some such thing just now, but please excuse some poking around in the dark here (I've disassembled code exactly once before: yesterday, in answering a similar request for more info in another lkml thread..). I'm actually not even certain the sequel is what you are asking. I couldn't find the set_idt symbol in arch/x86/kernel/machine_kexec_32.o. Google seemed to think this has something to do with the 'static' marker for that function, so I made another commit differing from the previous one only in that it removes that marker (i.e. set_idt is now 'void' rather than 'static void'). I can now see that function with objdump. The relevant sections of objdump -D on the two files are: --- arch/x86/kernel/machine_kexec_32.o --- 00000180 : 180: e8 fc ff ff ff call 181 185: 55 push %ebp 186: 89 e5 mov %esp,%ebp 188: 83 ec 0c sub $0xc,%esp 18b: 89 45 f8 mov %eax,-0x8(%ebp) 18e: 66 89 55 f6 mov %dx,-0xa(%ebp) 192: 8d 45 f6 lea -0xa(%ebp),%eax 195: 65 8b 0d 14 00 00 00 mov %gs:0x14,%ecx 19c: 89 4d fc mov %ecx,-0x4(%ebp) 19f: 31 c9 xor %ecx,%ecx 1a1: ff 15 20 00 00 00 call *0x20 1a7: 8b 45 fc mov -0x4(%ebp),%eax 1aa: 65 33 05 14 00 00 00 xor %gs:0x14,%eax 1b1: 75 02 jne 1b5 1b3: c9 leave 1b4: c3 ret 1b5: e8 fc ff ff ff call 1b6 1ba: 8d b6 00 00 00 00 lea 0x0(%esi),%esi ---------------------------------------------- and --- arch/x86/kernel/idt.o --- 00000000 : 0: e8 fc ff ff ff call 1 5: 55 push %ebp 6: 89 e5 mov %esp,%ebp 8: 83 ec 0c sub $0xc,%esp b: 65 8b 15 14 00 00 00 mov %gs:0x14,%edx 12: 89 55 fc mov %edx,-0x4(%ebp) 15: 31 d2 xor %edx,%edx 17: 31 d2 xor %edx,%edx 19: 89 45 f8 mov %eax,-0x8(%ebp) 1c: 8d 45 f6 lea -0xa(%ebp),%eax 1f: 66 89 55 f6 mov %dx,-0xa(%ebp) 23: ff 15 20 00 00 00 call *0x20 29: 8b 45 fc mov -0x4(%ebp),%eax 2c: 65 33 05 14 00 00 00 xor %gs:0x14,%eax 33: 75 02 jne 37 35: c9 leave 36: c3 ret 37: e8 fc ff ff ff call 38 ------------------------------- I've also checked again that this newer compilation still gives a well-behaved kexec. > > 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.. > > Linus