Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!

From: Peter Zijlstra <peterz@infradead.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: Jiri Olsa <jolsa@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Jan Stancek <jstancek@redhat.com>
Subject: Re: [BUG] msr-trace.h:42 suspicious rcu_dereference_check() usage!
Date: Mon, 21 Nov 2016 18:18:53 +0100	[thread overview]
Message-ID: <20161121171853.GK3092@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20161121170612.GT26852@two.firstfloor.org>

On Mon, Nov 21, 2016 at 09:06:13AM -0800, Andi Kleen wrote:
> > > it got away with attached change.. but this rcu logic
> > > is far beyond me, so it's just wild guess.. ;-)
> > 
> > I think I prefer something like the below, that only annotates the one
> > RDMSR in question, instead of all of them.
> 
> It would be far better to just fix trace points that they always work.
> 
> This whole thing is a travesty: we have tens of thousands of lines of code in
> ftrace to support tracing in NMIs, but then "debug features"[1] like
> this come around and make trace points unusable for far more code than
> just the NMI handlers.

Not sure the idle handlers are more code than we have NMI code, but yes,
its annoying.

Its not ftrace as such though, its RCU, ftrace simply uses RCU to avoid
locking, as one does.

Biggest objection would be that the rcu_irq_enter_irqson() thing does
POPF and rcu_irq_exit_irqson() does again. So wrapping every tracepoint
with that is quite a few cycles.