From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932458AbbJULwl (ORCPT ); Wed, 21 Oct 2015 07:52:41 -0400 Received: from casper.infradead.org ([85.118.1.10]:54301 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932437AbbJULwk (ORCPT ); Wed, 21 Oct 2015 07:52:40 -0400 Date: Wed, 21 Oct 2015 13:52:38 +0200 From: Peter Zijlstra To: Steven Rostedt Cc: "Paul E. McKenney" , LKML Subject: Re: [RFC][PATCH] tracing: Have stack tracer force RCU to be watching Message-ID: <20151021115238.GN17308@twins.programming.kicks-ass.net> References: <20151020121031.2f9d72c1@gandalf.local.home> <20151020202528.GF5105@linux.vnet.ibm.com> <20151020173228.3e4edda5@gandalf.local.home> <20151021080142.GZ2881@worktop.programming.kicks-ass.net> <20151021073922.77e429f6@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151021073922.77e429f6@gandalf.local.home> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 21, 2015 at 07:39:22AM -0400, Steven Rostedt wrote: > On Wed, 21 Oct 2015 10:01:42 +0200 > Peter Zijlstra wrote: > > > > I should probably add a "if (in_nmi()) return" somewhere. > > > > But if there's an arch that doesn't use a separate NMI stack, the NMI > > might cause the largest stack, which would then remain invisible from > > the stack-tracer. > > > > Should we not instead fix the NMI-safety of this tracer? > > We could, but that should be a separate project, as that would require > doing everything lockless, which would require a redesign. Is that > worth it? I've no idea on either, not on how hard it would be to fix, nor on if its worth the effort. I suppose auditing which archs do not have dedicated NMI stacks might be a good first stab at things. x86 still uses an IST for NMIs, right? Andy's been changing things a lot lately, I'm not sure I'm up to date on this. > For now, the safe thing to do is the if (in_nmi()), but certainly, if > someone gets time to make it NMI safe, we can do that too. Sure, fix current holes first.