Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755362AbbB0T4s (ORCPT ); Fri, 27 Feb 2015 14:56:48 -0500 Received: from mail-la0-f43.google.com ([209.85.215.43]:44861 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754932AbbB0T4r (ORCPT ); Fri, 27 Feb 2015 14:56:47 -0500 MIME-Version: 1.0 In-Reply-To: <54EFF3E7.2070007@huawei.com> References: <1424931315-44482-1-git-send-email-wangnan0@huawei.com> <54EFF3E7.2070007@huawei.com> From: Andy Lutomirski Date: Fri, 27 Feb 2015 11:56:25 -0800 Message-ID: Subject: Re: [PATCH] x86, traps: install gates using IST after cpu_init(). To: Wang Nan Cc: Masami Hiramatsu , Steven Rostedt , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , X86 ML , Oleg Nesterov , Dave Hansen , "linux-kernel@vger.kernel.org" , Li Zefan 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: 1923 Lines: 59 On Thu, Feb 26, 2015 at 8:34 PM, Wang Nan wrote: > On 2015/2/26 23:14, Andy Lutomirski wrote: >> On Wed, Feb 25, 2015 at 10:15 PM, Wang Nan wrote: >>> X86_TRAP_NMI, X86_TRAP_DF and X86_TRAP_MC use their own stack. Those >>> stacks are invalid until cpu_init() installs TSS. >>> >>> This patch moves setting of the 3 gates after cpu_init(). >>> >>> Signed-off-by: Wang Nan >>> --- >>> >>> If I understand correctly, logically speaking the original code is >>> incorrect. However, there is no real bug caused by it for serval years. >>> I'm not sure whether this fix is practical or not. Fix them only for >>> logical correctness. >> >> Acked-by: Andy Lutomirski >> >> That being said, I'm pretty sure you're not fixing a bug here. > > Agree. > >> Delivery of an exception with no handler is every bit as fatal as >> delivery of an exception with a non-working IST handler. >> > > Just curious: in original code, what will happen if an NMI or MC raises after > 'set_intr_gate_ist(X86_TRAP_NMI, &nmi, NMI_STACK);' and before cpu_init()? > In my opinion, at that time the interrupt handler is set but IST is not ready. > > In addition, why it's never happened for real? Does it means NMI is possible > to be disabled? It means that no NMI sources are enabled (hopefully) that early. If they were, we'd be doomed -- AFAIK it's impossible to maintain a continuously valid IDT all the way through the transition from real mode to long mode. (Maybe I'm wrong and there's some trick that would work.) --Andy > > Thank you! > >> --Andy >> > > -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/