From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] tracing: Have stack tracer force RCU to be watching
Date: Wed, 21 Oct 2015 13:52:38 +0200 [thread overview]
Message-ID: <20151021115238.GN17308@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20151021073922.77e429f6@gandalf.local.home>
On Wed, Oct 21, 2015 at 07:39:22AM -0400, Steven Rostedt wrote:
> On Wed, 21 Oct 2015 10:01:42 +0200
> Peter Zijlstra <peterz@infradead.org> 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.
prev parent reply other threads:[~2015-10-21 11:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 16:10 [RFC][PATCH] tracing: Have stack tracer force RCU to be watching Steven Rostedt
2015-10-20 20:25 ` Paul E. McKenney
2015-10-20 21:32 ` Steven Rostedt
2015-10-20 23:48 ` Paul E. McKenney
2015-10-20 23:55 ` Steven Rostedt
2015-10-21 17:46 ` Steven Rostedt
2015-10-21 8:01 ` Peter Zijlstra
2015-10-21 11:39 ` Steven Rostedt
2015-10-21 11:52 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151021115238.GN17308@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.