linux-kernel - Re: Problem with CREATE_TRACE

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Apr 2009 23:09:14 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Problem with CREATE_TRACE_POINTS and recursion safety


On Wed, 15 Apr 2009, Jeremy Fitzhardinge wrote:

> Mathieu Desnoyers wrote:
> > Jeremy brings up an interesting point. Given that we might eventually
> > include a few tracepoint header files in a given C file, but with the
> > intent of only "creating" the tracepoint callbacks for few of these, the
> > global "CREATE_TRACE_POINTS" flag makes little sense and seems like it
> > will easily lead to link-time errors.
> >   
> 
> Yes, that's what I'm seeing.
> 
> > Maybe we could consider requiring something like the following solution :
> > 
> > In the .c file :
> > 
> > #define CREATE_TRACE_POINTS
> > #include <trace/subsysa.h>
> > #undef CREATE_TRACE_POINTS
> > 
> > #include <trace/subsysb.h>
> > 
> > Where subsysa has its trace points callbacks created, but subsysb
> > doesn't. This seems half-way understandable, at least.
> 
> But what if trace/subsysa.h includes some other headers to define some types
> it needs, which in turn ends up incidentally including trace/subsysc.h (either
> directly, or indirectly via any number of other headers?  Then it will end up
> instantiating tracepoints for subsysa and subsysc.  The only way to avoid it
> would be to impose an absolutely strict separation of type/constant definition
> headers from function/tracepoint ones.

I hate to do this because it adds some more work to the developer adding a 
new trace point header, but we could just remove the CREATE_TRACE_POINTS 
and do in the trace/events/*.h headers:

#ifdef CREATE_FOO_TRACE_POINTS
#include <trace/define_trace.h>
#endif

in all tracepoint headers. I originally had it this way with just the 
CREATE_TRACE_POINTS, but Christoph Hellwig and Mathieu both suggested 
putting that into define_trace.h.  It seems so much cleaner to keep it in 
define_trace.h, but if it is causing too many headaches, it may not be 
worth it :-/

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/