tracing: Fix bug when reading system filters on module removal
authorSteven Rostedt <srostedt@redhat.com>
Tue, 5 Jul 2011 15:36:06 +0000 (11:36 -0400)
committerSteven Rostedt <rostedt@goodmis.org>
Thu, 7 Jul 2011 15:19:18 +0000 (11:19 -0400)
commite9dbfae53eeb9fc3d4bb7da3df87fa9875f5da02
tree2a389b9c6a5fe08d4fb3a9ca96e753244963e1d9
parent140fe3b1ab9c082182ef13359fab4ddba95c24c3
tracing: Fix bug when reading system filters on module removal

The event system is freed when its nr_events is set to zero. This happens
when a module created an event system and then later the module is
removed. Modules may share systems, so the system is allocated when
it is created and freed when the modules are unloaded and all the
events under the system are removed (nr_events set to zero).

The problem arises when a task opened the "filter" file for the
system. If the module is unloaded and it removed the last event for
that system, the system structure is freed. If the task that opened
the filter file accesses the "filter" file after the system has
been freed, the system will access an invalid pointer.

By adding a ref_count, and using it to keep track of what
is using the event system, we can free it after all users
are finished with the event system.

Cc: <stable@kernel.org>
Reported-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
kernel/trace/trace.h
kernel/trace/trace_events.c
kernel/trace/trace_events_filter.c