Re: [PATCH -tip 0/2] Temporary RCU fixes for notrace and hotplug CPU

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> On Tue, Aug 25, 2009 at 10:00:47AM +0200, Ingo Molnar wrote:
> > 
> > btw., i'm still seeing crashes with the latest RCU bits:
> > 
> > [   20.621740] Testing event sys_enter_futex: OK
> > [   20.629738] Testing event sys_exit_futex: OK
> > [   20.637737] Testing event lock_acquire: [reboot]
> > 
> > Possibly due to infinite recursion as well. Config attached.
> 
> Color me confused...
> 
> Unless someone has a better idea, I will send in a patch that adds
> "notrace" to every RCU API member used by any file in the kernel
> that has "trace" in its name (excluding ptrace.c and rcutree_trace.c,
> of course).  This list is as follows:
> 
> 	call_rcu()
> 	call_rcu_sched()
> 	rcu_read_lock()
> 	rcu_read_unlock()
> 
> So, any better ideas?

Tracers using RCU should use the _notrace() version of read_lock/unlock.
I think the callers should be fixed rather than RCU.

Tracepoints have been designed to use the _notrace variant on the
instrumentation site. The core of tracepoint management use
call_rcu_sched(), which can be traced without any problem.

I have not followed the late tracing development as closely though, so
errors might have crept in.

Mathieu

> 
> 							Thanx, Paul

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68