On Fri, 11 May 2018 06:14:07 +0200 Juergen Gross <jgross@xxxxxxxx> wrote: > Any reason not sending this patch to the Xen maintainers? Nope, I guess I should have run the patch through "get_maintainer.pl". > > I can take it through the Xen tree. :-) Thanks! > > Reviewed-by: Juergen Gross <jgross@xxxxxxxx> Note, I'm going to be adding the below patch for 4.18 (or 5.0) which will cause the build to break in case there's any more instances of this. -- Steve >From 8f8125877582345dd68f865f76442dda9204c0c1 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" <rostedt@xxxxxxxxxxx> Date: Thu, 10 May 2018 12:40:21 -0400 Subject: [PATCH] tracing: Prevent further users of zero size static arrays in trace events A zero size static array has special meaning in the ftrace infrastructure. Trace events are for recording data in the trace buffers that is normally difficult to obtain via probes or function tracing. There is no reason for any trace event to declare a zero size static array. If one does, BUILD_BUG_ON() will trigger and prevent the kernel from compiling. Signed-off-by: Steven Rostedt (VMware) <rostedt@xxxxxxxxxxx> --- include/trace/trace_events.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h index bfda803b0a09..4ecdfe2e3580 100644 --- a/include/trace/trace_events.h +++ b/include/trace/trace_events.h @@ -422,6 +422,7 @@ static struct trace_event_functions trace_event_type_funcs_##call = { \ do { \ char *type_str = #type"["__stringify(len)"]"; \ BUILD_BUG_ON(len > MAX_FILTER_STR_VAL); \ + BUILD_BUG_ON(len <= 0); \ ret = trace_define_field(event_call, type_str, #item, \ offsetof(typeof(field), item), \ sizeof(field.item), \ -- 2.13.6