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

Mathieu Desnoyers
2009-08-25T16:25:50Z

* 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