mirror of
https://github.com/adulau/aha.git
synced 2024-12-29 12:16:20 +00:00
9456f0fa6d
Li Zefan found that there's a race using the event ids of events and modules. When a module is loaded, an event id is incremented. We only have 16 bits for event ids (65536) and there is a possible (but highly unlikely) race that we could load and unload a module that registers events so many times that the event id counter overflows. When it overflows, it then restarts and goes looking for available ids. An id is available if it was added by a module and released. The race is if you have one module add an id, and then is removed. Another module loaded can use that same event id. But if the old module still had events in the ring buffer, the new module's call back would get bogus data. At best (and most likely) the output would just be garbage. But if the module for some reason used pointers (not recommended) then this could potentially crash. The safest thing to do is just reset the ring buffer if a module that registered events is removed. [ Impact: prevent unpredictable results of event id overflows ] Reported-by: Li Zefan <lizf@cn.fujitsu.com> LKML-Reference: <49FEAFD0.30106@cn.fujitsu.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org> |
||
---|---|---|
.. | ||
blktrace.c | ||
ftrace.c | ||
Kconfig | ||
kmemtrace.c | ||
Makefile | ||
ring_buffer.c | ||
ring_buffer_benchmark.c | ||
trace.c | ||
trace.h | ||
trace_boot.c | ||
trace_branch.c | ||
trace_clock.c | ||
trace_event_profile.c | ||
trace_event_types.h | ||
trace_events.c | ||
trace_events_filter.c | ||
trace_export.c | ||
trace_functions.c | ||
trace_functions_graph.c | ||
trace_hw_branches.c | ||
trace_irqsoff.c | ||
trace_mmiotrace.c | ||
trace_nop.c | ||
trace_output.c | ||
trace_output.h | ||
trace_power.c | ||
trace_printk.c | ||
trace_sched_switch.c | ||
trace_sched_wakeup.c | ||
trace_selftest.c | ||
trace_selftest_dynamic.c | ||
trace_stack.c | ||
trace_stat.c | ||
trace_stat.h | ||
trace_syscalls.c | ||
trace_sysprof.c | ||
trace_workqueue.c |