[PATCH 0/7] tracing: instance_rmdir() leaks ftrace_event_file->filter

[Oleg Nesterov]

Hello,

Sorry for delay, I was distracted by other problems.

To remind, we discussed the potential uprobes "mix perf/ftrace" changes and
found some off-topic problems. Lets start with ->filter fixes/cleanups.

So far I didn't even try to test this series, although it looks simple except
perhaps the last patch. I'll try to somehow test this tomorrow, but I do not
really now how.

So please review, these patches need acks anyway.

As for 1/7, I added BUG_ON(file->filter) into remove_event_file_dir() before
kmem_cache_free() to verify that yes, the leak does exist. Perhaps this patch
should go to stable, or at least to v3.16.

--------------------------------------------------------------------------------
And could someone explain me why apply_subsystem_event_filter("0") clears
->filter_string first, then the whole ->filter? It seems that the only
thing filter_free_subsystem_preds() should do is filter_disable(), no?
IOW, why the patch below (on top of this series) is wrong?

Oleg.

--- x/kernel/trace/trace_events_filter.c
+++ x/kernel/trace/trace_events_filter.c
@@ -831,17 +831,6 @@ static int __alloc_preds(struct event_filter *filter, int n_preds)
 	return 0;
 }
 
-static inline void __remove_filter(struct ftrace_event_file *file)
-{
-	struct ftrace_event_call *call = file->event_call;
-
-	filter_disable(file);
-	if (call->flags & TRACE_EVENT_FL_USE_CALL_FILTER)
-		remove_filter_string(call->filter);
-	else
-		remove_filter_string(file->filter);
-}
-
 static void filter_free_subsystem_preds(struct event_subsystem *system,
 					struct trace_array *tr)
 {
@@ -850,7 +839,7 @@ static void filter_free_subsystem_preds(struct event_subsystem *system,
 	list_for_each_entry(file, &tr->events, list) {
 		if (file->system->subsystem != system)
 			continue;
-		__remove_filter(file);
+		filter_disable(file);
 	}
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/