aboutsummaryrefslogtreecommitdiffstats
path: root/kernel/trace/trace_export.c
diff options
context:
space:
mode:
authorTom Zanussi <tzanussi@gmail.com>2009-04-13 04:17:50 -0400
committerIngo Molnar <mingo@elte.hu>2009-04-13 18:03:55 -0400
commit0a19e53c1514ad8e9c3cbab40c6c3f52c86f403d (patch)
tree1089246a64f65b2b3c2ba29182ed4f9ce9ad375e /kernel/trace/trace_export.c
parentb5c851a88a369854c04e511cefb84ea2d0cfa209 (diff)
tracing/filters: allow on-the-fly filter switching
This patch allows event filters to be safely removed or switched on-the-fly while avoiding the use of rcu or the suspension of tracing of previous versions. It does it by adding a new filter_pred_none() predicate function which does nothing and by never deallocating either the predicates or any of the filter_pred members used in matching; the predicate lists are allocated and initialized during ftrace_event_calls initialization. Whenever a filter is removed or replaced, the filter_pred_* functions currently in use by the affected ftrace_event_call are immediately switched over to to the filter_pred_none() function, while the rest of the filter_pred members are left intact, allowing any currently executing filter_pred_* functions to finish up, using the values they're currently using. In the case of filter replacement, the new predicate values are copied into the old predicates after the above step, and the filter_pred_none() functions are replaced by the filter_pred_* functions for the new filter. In this case, it is possible though very unlikely that a previous filter_pred_* is still running even after the filter_pred_none() switch and the switch to the new filter_pred_*. In that case, however, because nothing has been deallocated in the filter_pred, the worst that can happen is that the old filter_pred_* function sees the new values and as a result produces either a false positive or a false negative, depending on the values it finds. So one downside to this method is that rarely, it can produce a bad match during the filter switch, but it should be possible to live with that, IMHO. The other downside is that at least in this patch the predicate lists are always pre-allocated, taking up memory from the start. They could probably be allocated on first-use, and de-allocated when tracing is completely stopped - if this patch makes sense, I could create another one to do that later on. Oh, and it also places a restriction on the size of __arrays in events, currently set to 128, since they can't be larger than the now embedded str_val arrays in the filter_pred struct. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> Acked-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: paulmck@linux.vnet.ibm.com LKML-Reference: <1239610670.6660.49.camel@tropicana> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/trace/trace_export.c')
-rw-r--r--kernel/trace/trace_export.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/kernel/trace/trace_export.c b/kernel/trace/trace_export.c
index 77c494f5e1d6..48fc02fe73a0 100644
--- a/kernel/trace/trace_export.c
+++ b/kernel/trace/trace_export.c
@@ -122,6 +122,7 @@ __attribute__((section("_ftrace_events"))) event_##call = { \
122static int ftrace_raw_init_event_##call(void) \ 122static int ftrace_raw_init_event_##call(void) \
123{ \ 123{ \
124 INIT_LIST_HEAD(&event_##call.fields); \ 124 INIT_LIST_HEAD(&event_##call.fields); \
125 init_preds(&event_##call); \
125 return 0; \ 126 return 0; \
126} \ 127} \
127 128