On Fri, May 4, 2018 at 4:42 PM Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote: [..] > > Say that the tracepoint code is buggy and for some reason a > > call_srcu wasn't done. For example, say the hypothetical bug I'm > > taking about is in tracepoint_remove_func which called the > > rcu_assign_pointer, but didn't call release_probes: > > > > diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c > > index d0639d917899..f54cb358f451 100644 > > --- a/kernel/tracepoint.c > > +++ b/kernel/tracepoint.c > > @@ -216,7 +216,6 @@ static int tracepoint_add_func(struct tracepoint *tp, > > rcu_assign_pointer(tp->funcs, tp_funcs); > > if (!static_key_enabled(&tp->key)) > > static_key_slow_inc(&tp->key); > > - release_probes(old); > > return 0; > > } > > --- > > I want to catching this from the test code. If I did the following, > > it would be insufficient then: > > > > trace_probe_register(...); > > srcu_barrier(&my_srcu_struct); // only tells me any queued calls > > // are done but not that something > > // was queued > > > > I was seeing if I could use my_srcu_struct::completed for that. but > > I'm not sure if that'll work (or that its legal to access it > > directly - but hey this is just test code! :P).
> This is a bit ugly to do programmatically in the kernel. The callbacks > are on per-CPU queues that cannot be safely accessed except by that CPU. > Plus they are on singly linked lists that can be quite long, so it could > be insanely slow as well. > But given that this is test code, why not leverage event tracing? > There are some relevant events in include/trace/events/rcu.h, starting > with the rcu_callback trace event. Sounds like a great idea. I'll try that, thanks. - Joel