Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752799AbdLYOki (ORCPT ); Mon, 25 Dec 2017 09:40:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:37800 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752210AbdLYOkg (ORCPT ); Mon, 25 Dec 2017 09:40:36 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 85F132190E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=luto@kernel.org X-Google-Smtp-Source: ACJfBoufUUGtI0CAO0LBOhnU7KkZHPu8yTi0ajZTSG0vHzD0Vwz41Ri8ljiO+QpAgWV8Vq3kP8/W0NpxUbCKeiWAcBQ= MIME-Version: 1.0 In-Reply-To: References: <20171224014415.GA5663@chirva-void> From: Andy Lutomirski Date: Mon, 25 Dec 2017 06:40:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot To: Linus Torvalds Cc: Alexandru Chirvasitu , Thomas Gleixner , kernel list , Andy Lutomirski , Borislav Petkov , Brian Gerst , Denys Vlasenko , "H. Peter Anvin" , Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1439 Lines: 41 On Sat, Dec 23, 2017 at 7:30 PM, 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()"? > >> 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