Re: linux-next: build failure after merge of the kspp tree

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 25 Jan 2022 22:27:32 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:

> > But if this is true, I would imagine there would be plenty of other
> > warnings? I'm currently stumped.  
> 
> That is because __rel_loc is used only in the sample code in the kernel
> for testing. Other use-cases comes from user-space.
> Hmm, can we skip this boundary check for this example?

Is this only checked when __CHECKER__ is defined? If so, would this work?

-- Steve

diff --git a/samples/trace_events/trace-events-sample.h b/samples/trace_events/trace-events-sample.h
index cbbbb83beced..cdc68e0f9ef9 100644
--- a/samples/trace_events/trace-events-sample.h
+++ b/samples/trace_events/trace-events-sample.h
@@ -506,6 +506,8 @@ DEFINE_EVENT_PRINT(foo_template, foo_with_template_print,
 	TP_ARGS(foo, bar),
 	TP_printk("bar %s %d", __get_str(foo), __entry->bar));
 
+/* rel_loc is for user defined events, the checker will trigger bugs on it */
+#ifndef __CHECKER__
 /*
  * There are yet another __rel_loc dynamic data attribute. If you
  * use __rel_dynamic_array() and __rel_string() etc. macros, you
@@ -539,6 +541,10 @@ TRACE_EVENT(foo_rel_loc,
 	TP_printk("foo_rel_loc %s, %d, %s", __get_rel_str(foo), __entry->bar,
 		  __get_rel_bitmask(bitmask))
 );
+#else
+#define trace_foo_rel_loc(foo, bar, mask) do { } while (0)
+#endif /* __CHECKER __ */
+
 #endif
 
 /***** NOTICE! The #if protection ends here. *****/