[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54c0a807-87e3-866f-aaa8-de383d567d50@suse.com>
Date: Fri, 11 May 2018 06:14:07 +0200
From: Juergen Gross <jgross@...e.com>
To: Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Jingjie Jiang <jingjie.jiang@...cle.com>,
Mukesh Rathor <mukesh.rathor@...cle.com>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
stable@...r.kernel.org
Subject: Re: [PATCH] tracing/x86/xen: Remove zero data size trace events
trace_xen_mmu_flush_tlb{_all}
On 09/05/18 20:46, Steven Rostedt wrote:
>
> From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
>
> 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!
>
> Cc: stable@...r.kernel.org
> Fixes: 95a7d76897c1e ("xen/mmu: Use Xen specific TLB flush instead of the generic one.")
> Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
Any reason not sending this patch to the Xen maintainers?
I can take it through the Xen tree. :-)
Reviewed-by: Juergen Gross <jgross@...e.com>
Juergen
Powered by blists - more mailing lists