From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932325AbcGZS4o (ORCPT ); Tue, 26 Jul 2016 14:56:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55338 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751261AbcGZS4m (ORCPT ); Tue, 26 Jul 2016 14:56:42 -0400 Date: Tue, 26 Jul 2016 13:56:37 -0500 From: Josh Poimboeuf To: Steven Rostedt Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Brian Gerst , Kees Cook , Peter Zijlstra , Frederic Weisbecker , Byungchul Park Subject: Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface Message-ID: <20160726185637.u5vilk3k4v2ztlac@treble> References: <88568c51f1a253210897e368262d0f5fa1d7e97a.1469136008.git.jpoimboe@redhat.com> <20160722235459.xtikpj263hroloqo@treble> <20160723140439.36bhw5aslcxlkf3f@treble> <20160726162642.e3ro4ynrgex74232@treble> <20160726135127.5e3daf44@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160726135127.5e3daf44@gandalf.local.home> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 26 Jul 2016 18:56:41 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 26, 2016 at 01:51:27PM -0400, Steven Rostedt wrote: > On Tue, 26 Jul 2016 11:26:42 -0500 > Josh Poimboeuf wrote: > > > > Ok, I think that makes sense to me now. As I understand it, the > > "outermost" RIP is the authoritative one, because it was written by the > > original NMI. Any nested NMIs will update the original and/or iret > > RIPs, which will only ever point to NMI entry code, and so they should > > be ignored. > > Just to confirm: > > -- top-of-stack -- > [ hardware written stack ] <- what the NMI hardware mechanism wrote > [ internal variables ] <- you don't need to know what this is > [ where to go next ] <- the stack to use to return on current NMI > [ original copy of hardware stack ] <- the stack of the first NMI > > IIRC, the original version had the "where to go next" stack last, but > to keep pt_regs in line with the stack, it made sense to have the > original NMI stack at the bottom, just above pt_regs, like a real > interrupt would. > > > > > But I think there's a case where this wouldn't work: > > > > task stack > > NMI > > IST > > stack dump > > > > If the IST interrupt hits before the NMI has a chance to update the > > outermost regs, the authoritative RIP would be the original one written > > by HW, right? > > The only IST interrupt that would hit there is MCE and it would > probably be a critical error. Do we really need to worry about such an > unlikely scenario? The system is probably doomed anyway. According to entry_64.S: /* * We allow breakpoints in NMIs. If a breakpoint occurs, then * the iretq it performs will take us out of NMI context. * This means that we can have nested NMIs where the next * NMI is using the top of the stack of the previous NMI. So I think this means that when a debug exception returns to an NMI with iret, further NMIs are no longer masked. -- Josh