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

From: Steven Rostedt
Date: Tue Jan 25 2022 - 09:05:38 EST


On Tue, 25 Jan 2022 22:27:32 +0900
Masami Hiramatsu <mhiramat@xxxxxxxxxx> 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. *****/