From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Dave Hansen <dave@sr71.net>,
linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com,
davej@redhat.com, mingo@redhat.com
Subject: Re: [PATCH] tracing: generate RCU warnings even when tracepoints are disabled
Date: Fri, 8 Aug 2014 11:42:30 -0700 [thread overview]
Message-ID: <20140808184230.GE5821@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140808143022.5262f6cb@gandalf.local.home>
On Fri, Aug 08, 2014 at 02:30:22PM -0400, Steven Rostedt wrote:
> On Thu, 7 Aug 2014 11:13:56 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Thu, Aug 07, 2014 at 10:52:04AM -0700, Dave Hansen wrote:
> > >
> > > From: Dave Hansen <dave.hansen@linux.intel.com>
> > >
> > > Dave Jones reported seeing a bug from one of my TLB tracepoints:
> > >
> > > http://lkml.kernel.org/r/20140806181801.GA4605@redhat.com
> > >
> > > I've been running these patches for months and never saw this.
> > > But, a big chunk of my testing, especially with all the debugging
> > > enabled, was in a vm where intel_idle doesn't work. On the
> > > systems where I was using intel_idle, I never had lockdep enabled
> > > and this tracepoint on at the same time.
> > >
> > > This patch ensures that whenever we have lockdep available, we do
> > > _some_ RCU activity at the site of the tracepoint, despite
> > > whether the tracepoint's condition matches or even if the
> > > tracepoint itself is completely disabled. This is a bit of a
> > > hack, but it is pretty self-contained.
> > >
> > > I confirmed that with this patch plus lockdep I get the same
> > > splat as Dave Jones did, but without enabling the tracepoint
> > > explicitly.
> > >
> > > Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> > > Cc: Dave Jones <davej@redhat.com>,
> > > Cc: paulmck@linux.vnet.ibm.com
> > > Cc: Steven Rostedt <rostedt@goodmis.org>
> > > Cc: Ingo Molnar <mingo@redhat.com>
> >
> > Looks good to me, but I must defer to Steven on this one.
>
> Looks fine. I can add it to my 3.18 queue.
>
> Paul, want to send me an "Acked-by"?
Here you go:
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Thanx, Paul
prev parent reply other threads:[~2014-08-08 18:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-07 17:52 [PATCH] tracing: generate RCU warnings even when tracepoints are disabled Dave Hansen
2014-08-07 18:13 ` Paul E. McKenney
2014-08-08 18:30 ` Steven Rostedt
2014-08-08 18:42 ` 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=20140808184230.GE5821@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@sr71.net \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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.