summaryrefslogtreecommitdiffstats
path: root/kernel/trace
diff options
context:
space:
mode:
authorSteven Rostedt (VMware) <rostedt@goodmis.org>2018-05-09 20:36:09 +0200
committerSteven Rostedt (VMware) <rostedt@goodmis.org>2018-05-14 23:02:30 +0200
commit45dd9b0666a162f8e4be76096716670cf1741f0e (patch)
tree5d4fe81b9dd5555baac5e86ebd231a928cf2b126 /kernel/trace
parenttracing: Fix regex_match_front() to not over compare the test string (diff)
downloadlinux-45dd9b0666a162f8e4be76096716670cf1741f0e.tar.xz
linux-45dd9b0666a162f8e4be76096716670cf1741f0e.zip
tracing/x86/xen: Remove zero data size trace events trace_xen_mmu_flush_tlb{_all}
Doing an audit of trace events, I discovered two trace events in the xen subsystem that use a hack to create zero data size trace events. This is not what trace events are for. Trace events add memory footprint overhead, and if all you need to do is see if a function is hit or not, simply make that function noinline and use function tracer filtering. Worse yet, the hack used was: __array(char, x, 0) Which creates a static string of zero in length. There's assumptions about such constructs in ftrace that this is a dynamic string that is nul terminated. This is not the case with these tracepoints and can cause problems in various parts of ftrace. Nuke the trace events! Link: http://lkml.kernel.org/r/20180509144605.5a220327@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.") Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Diffstat (limited to 'kernel/trace')
0 files changed, 0 insertions, 0 deletions