From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3qxWDB2zWCzDqBr for ; Sat, 30 Apr 2016 10:10:18 +1000 (AEST) Received: by mail-ob0-x235.google.com with SMTP id x1so39963418obt.0 for ; Fri, 29 Apr 2016 17:10:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20160429201139.pudoged2yathyo64@treble> <20160429202701.yijrohqdsurdxv2a@treble> <20160429212546.t26mvthtvh7543ff@treble> From: Andy Lutomirski Date: Fri, 29 Apr 2016 17:09:56 -0700 Message-ID: Subject: Re: [RFC PATCH v2 05/18] sched: add task flag for preempt IRQ tracking To: Jiri Kosina Cc: Ingo Molnar , Josh Poimboeuf , X86 ML , Heiko Carstens , "linux-s390@vger.kernel.org" , live-patching@vger.kernel.org, Michael Ellerman , Chris J Arges , linuxppc-dev@lists.ozlabs.org, Jessica Yu , Petr Mladek , Jiri Slaby , Vojtech Pavlik , "linux-kernel@vger.kernel.org" , Miroslav Benes , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Apr 29, 2016 3:11 PM, "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? > On x86, at least, there will still be pt_regs for the NMI. For the interrupted state, though, there might not be pt_regs, as the NMI might have happened while still populating pt_regs. In fact, the NMI stack could overlap task_pt_regs. For x86_32, there's no guarantee that pt_regs contains sp due to hardware silliness. You need to parse it more carefully, as, !user_mode(regs), then the old sp is just above pt_regs. --Andy