All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2] tracing: Make sure RCU is watching before calling a stack trace
Date: Thu, 18 May 2017 12:50:54 -0700	[thread overview]
Message-ID: <20170518195054.GY3956@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170518153026.053b2c82@gandalf.local.home>

On Thu, May 18, 2017 at 03:30:26PM -0400, Steven Rostedt wrote:
> On Thu, 18 May 2017 11:45:28 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > On Thu, May 18, 2017 at 12:39:14PM -0400, Steven Rostedt wrote:
> > > On Thu, 18 May 2017 08:47:11 -0700
> > > "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> > >   
> > > > On Thu, May 18, 2017 at 09:38:09AM -0400, Steven Rostedt wrote:  
> > > > > 
> > > > > From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> > > > > 
> > > > > As stack tracing now requires "rcu watching", force RCU to be watching when
> > > > > recording a stack trace.
> > > > > 
> > > > > Link: http://lkml.kernel.org/r/20170512172449.879684501@goodmis.org
> > > > > 
> > > > > Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > > > Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > > > > ---
> > > > > 
> > > > > Changes since v1:
> > > > > 
> > > > >    My testing discovered that the stack trace can be called with
> > > > >    interrupts enabled, which is a no no to have when calling
> > > > >    rcu_irq_enter(). When interrupts are enabled, as with being in an
> > > > >    NMI, RCU will also be watching.
> > > > > 
> > > > > kernel/trace/trace.c | 26 +++++++++++++++++++++++++-
> > > > >  1 file changed, 25 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> > > > > index fcc9a2d..34a98ba 100644
> > > > > --- a/kernel/trace/trace.c
> > > > > +++ b/kernel/trace/trace.c
> > > > > @@ -2568,7 +2568,31 @@ static inline void ftrace_trace_stack(struct trace_array *tr,
> > > > >  void __trace_stack(struct trace_array *tr, unsigned long flags, int skip,
> > > > >  		   int pc)
> > > > >  {
> > > > > -	__ftrace_trace_stack(tr->trace_buffer.buffer, flags, skip, pc, NULL);
> > > > > +	struct ring_buffer *buffer = tr->trace_buffer.buffer;
> > > > > +
> > > > > +	/*
> > > > > +	 * When an NMI triggers, RCU is enabled via rcu_nmi_enter()
> > > > > +	 * Also, RCU is always enabled when interrupts are.
> > > > > +	 */
> > > > > +	if (!irqs_disabled() || in_nmi()) {    
> > > > 
> > > > You lost me on this one.  RCU might not be watching if irqs are
> > > > enabled, for example, in the idle loop.  What am I missing here?
> > > >   
> > > 
> > > Hmm, no, maybe I'm missing something :-/
> > > 
> > > OK, so if we trace in the idle loop, rcu may not be watching, so I may
> > > need to byte the bullet and use the rcu_irq_enter_irqon() instead :-(  
> > 
> > If rcu_is_watching() returns false, yes.  Of course, if rcu_is_watching()
> > returns true, you are golden.
> > 
> 
> Hmm, so I can just replace the entire if with:
> 
> 	if (rcu_is_watching())
> 
> because it should be watching in NMI context, correct?

Yes, and that would be even better!  ;-)

However, this assumes that there is no possibility of this being called
during the time that in_nmi() returns true but RCU is not aware of the
NMI.  (Yes, we did go through this a bit earlier, just my usual paranoia
showing...)

							Thanx, Paul

      reply	other threads:[~2017-05-18 19:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 13:38 [PATCH v2] tracing: Make sure RCU is watching before calling a stack trace Steven Rostedt
2017-05-18 13:48 ` Miroslav Benes
2017-05-18 14:04   ` Steven Rostedt
2017-05-18 18:18     ` Miroslav Benes
2017-05-18 14:50 ` Steven Rostedt
2017-05-18 15:47 ` Paul E. McKenney
2017-05-18 16:39   ` Steven Rostedt
2017-05-18 18:45     ` Paul E. McKenney
2017-05-18 19:30       ` Steven Rostedt
2017-05-18 19:50         ` Paul E. McKenney [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=20170518195054.GY3956@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.