From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3qxTcq0mMXzDq6B for ; Sat, 30 Apr 2016 08:58:02 +1000 (AEST) Date: Fri, 29 Apr 2016 17:57:57 -0500 From: Josh Poimboeuf To: Jiri Kosina Cc: Andy Lutomirski , Jessica Yu , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, "linux-kernel@vger.kernel.org" , X86 ML , linuxppc-dev@lists.ozlabs.org, "linux-s390@vger.kernel.org" , Vojtech Pavlik , Jiri Slaby , Petr Mladek , Chris J Arges , Andy Lutomirski Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking Message-ID: <20160429225757.n7mjjysomnf5ns53@treble> References: <20160429201139.pudoged2yathyo64@treble> <20160429202701.yijrohqdsurdxv2a@treble> <20160429212546.t26mvthtvh7543ff@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Apr 30, 2016 at 12:11:45AM +0200, Jiri Kosina wrote: > On Fri, 29 Apr 2016, Andy Lutomirski wrote: > > > NMI, MCE and interrupts aren't a problem because they have dedicated > > > stacks, which are easy to detect. If the tasks' stack is on an > > > exception stack or an irq stack, we consider it unreliable. > > > > Only on x86_64. > > Well, MCEs are more or less x86-specific as well. But otherwise good > point, thanks Andy. > > So, how does stack layout generally look like in case when NMI is actually > running on proper kernel stack? I thought it's guaranteed to contain > pt_regs anyway in all cases. Is that not guaranteed to be the case? If the NMI were using the normal kernel stack and it interrupted kernel space, pt_regs would be placed in the "middle" of the stack rather than the bottom, and there's currently no way to detect that. However, NMIs don't sleep, and we only consider sleeping tasks for stack reliability, so it wouldn't be an issue anyway. -- Josh