lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 Sep 2020 13:42:25 -0400 (EDT) From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com> To: rostedt <rostedt@...dmis.org> Cc: linux-kernel <linux-kernel@...r.kernel.org>, Yafang Shao <laoar.shao@...il.com>, Axel Rasmussen <axelrasmussen@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, Vlastimil Babka <vbabka@...e.cz>, Michel Lespinasse <walken@...gle.com>, Daniel Jordan <daniel.m.jordan@...cle.com>, Davidlohr Bueso <dbueso@...e.de>, linux-mm <linux-mm@...ck.org>, Ingo Molnar <mingo@...nel.org>, Joonsoo Kim <iamjoonsoo.kim@....com> Subject: Re: [PATCH 1/2] tracepoints: Add helper to test if tracepoint is enabled in a header ----- On Sep 24, 2020, at 1:09 PM, rostedt rostedt@...dmis.org wrote: > From: "Steven Rostedt (VMware)" <rostedt@...dmis.org> > > As tracepoints are discouraged from being added in a header because it can > cause side effects if other tracepoints are in headers, the common > workaround is to add a function call that calls a wrapper function in a > C file that then calls the tracepoint. But as function calls add overhead, > this function should only be called when the tracepoint in question is > enabled. To get around the overhead, a static_branch can be used that only > gets set when the tracepoint is enabled, and then inside the block of the > static branch can contain the call to the tracepoint wrapper. > > Add a tracepoint_enabled(tp) macro that gets passed the name of the > tracepoint, and this becomes a static_branch that is enabled when the > tracepoint is enabled and is a nop when the tracepoint is disabled. > > Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org> > --- > Documentation/trace/tracepoints.rst | 25 ++++++++++++++++++++++ > include/linux/tracepoint-defs.h | 33 +++++++++++++++++++++++++++++ > 2 files changed, 58 insertions(+) > > diff --git a/Documentation/trace/tracepoints.rst > b/Documentation/trace/tracepoints.rst > index 6e3ce3bf3593..833d39ee1c44 100644 > --- a/Documentation/trace/tracepoints.rst > +++ b/Documentation/trace/tracepoints.rst > @@ -146,3 +146,28 @@ with jump labels and avoid conditional branches. > define tracepoints. Check http://lwn.net/Articles/379903, > http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362 > for a series of articles with more details. > + > +If you require calling a tracepoint from a header file, it is not > +recommended to call one directly or to use the trace_<tracepoint>_enabled() > +function call, as tracepoints in header files can have side effects if a > +header is included from a file that has CREATE_TRACE_POINTS set. Instead, > +include tracepoint-defs.h and use trace_enabled(). Tracepoints per-se have no issues being used from header files. The TRACE_EVENT infrastructure seems to be the cause of this problem. We should fix trace events rather than require all users to use weird work-arounds thorough the kernel code base. I am not against the idea of a tracepoint_enabled(tp), but I am against the motivation behind this patch and the new tracepoint user requirements it documents. > + > +In a C file:: > + > + void do_trace_foo_bar_wrapper(args) > + { > + trace_foo_bar(args); > + } > + > +In the header file:: > + > + DECLEARE_TRACEPOINT(foo_bar); > + > + static inline void some_inline_function() > + { > + [..] > + if (trace_enabled(foo_bar)) Is it trace_enabled() or tracepoint_enabled() ? There is a mismatch between the commit message/code and the documentation. Thanks, Mathieu > + do_trace_foo_bar_wrapper(args); > + [..] > + } > diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h > index b29950a19205..ca2f1f77f6f8 100644 > --- a/include/linux/tracepoint-defs.h > +++ b/include/linux/tracepoint-defs.h > @@ -48,4 +48,37 @@ struct bpf_raw_event_map { > u32 writable_size; > } __aligned(32); > > +/* > + * If a tracepoint needs to be called from a header file, it is not > + * recommended to call it directly, as tracepoints in header files > + * may cause side-effects. Instead, use trace_enabled() to test > + * if the tracepoint is enabled, then if it is, call a wrapper > + * function defined in a C file that will then call the tracepoint. > + * > + * For "trace_foo()", you would need to create a wrapper function > + * in a C file to call trace_foo(): > + * void trace_bar(args) { trace_foo(args); } > + * Then in the header file, declare the tracepoint: > + * DECLARE_TRACEPOINT(foo); > + * And call your wrapper: > + * static inline void some_inlined_function() { > + * [..] > + * if (tracepoint_enabled(foo)) > + * trace_bar(args); > + * [..] > + * } > + * > + * Note: tracepoint_enabled(foo) is equivalent to trace_foo_enabled() > + * but is safe to have in headers, where trace_foo_enabled() is not. > + */ > +#define DECLARE_TRACEPOINT(tp) \ > + extern struct tracepoint __tracepoint_##tp > + > +#ifdef CONFIG_TRACEPOINTS > +# define tracepoint_enabled(tp) \ > + static_key_false(&(__tracepoint_##tp).key) > +#else > +# define tracepoint_enabled(tracepoint) false > +#endif > + > #endif > -- > 2.28.0 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
Powered by blists - more mailing lists