Messages in this thread | | | Date | Fri, 3 Apr 2009 15:59:56 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH] tracing/filters: allow event filters to be set only when not tracing |
| |
* Tom Zanussi <tzanussi@gmail.com> wrote:
> On Wed, 2009-04-01 at 14:24 +0200, Ingo Molnar wrote: > > * Tom Zanussi <tzanussi@gmail.com> wrote: > > > > > This patch adds code allowing the event filter to be set only if > > > there's no active tracing going on. > > > > > --- a/kernel/trace/trace_events.c > > > +++ b/kernel/trace/trace_events.c > > > @@ -498,6 +498,9 @@ event_filter_write(struct file *filp, const char __user *ubuf, size_t cnt, > > > struct filter_pred *pred; > > > int err; > > > > > > + if (tracing_is_enabled() && (!tracer_is_nop() || call->enabled)) > > > + return -EBUSY; > > > > hm, but it would be the normal use-case to set filters on the fly. > > To experiment around with them and shape them until the output is > > just right. Having to turn the tracer on/off during that seems quite > > counterproductive to that use-case. > > > > I didn't see anything that could be used to temporarily disable > tracing (tracing_stop() and tracing_start() are 'quick' versions > that mostly just disable recording), so did it this way to avoid > adding any overhead to the filter-checking code. > > But anyway, I'll post a new patch shortly that uses rcu and does > allow the filters to be set on the fly.
that's a very intelligent way to do it!
There's a theoretical problem though: what if we put a filtered tracepoint into the RCU code? Especially if that tracepoint is in the common function-tracer callback affecting all kernel functions. I've Cc:-ed Paul. I think the quiescent state logic should handle this just fine, but i'm not 100% sure.
Ingo
| |