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]

Message-ID: <alpine.DEB.2.00.0904152042350.4459@gandalf.stny.rr.com>
Date:	Wed, 15 Apr 2009 20:56:28 -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:

> I'm having a problem with CREATE_TRACE_POINTS being too indiscriminate.  The
> trouble is that it not only creates tracepoint definitions for the intended
> tracepoints, but any other tracepoint definitions which get included
> incidentally.
> 
> For example, I'm seeing my paravirt tracepoints being instantiated in both
> kernel/sched.o and kernel/irq/manage.o as side-effects of the scheduler and
> irq tracepoints being instantiated.
> 
> I'm experimenting with a different scheme, wherein a subsystem defines
> CREATE_FOO_TRACE_POINTS in the .c file where it wants to instantiate the
> tracepoints - rather than CREATE_TRACE_POINTS - and its trace/events/foo.h
> does:
> 
>    #ifdef CREATE_FOO_TRACE_POINTS
>    #undef CREATE_FOO_TRACE_POINTS	/* avoid infinite recursion */
>    #include <trace/instantiate_trace.h>
>    #else
>    #include <trace/define_trace.h>
>    #endif
> 
> where instantiate_trace.h is:
> 
>    #define CREATE_TRACE_POINTS
>    #include <trace/define_trace.h>
>    #undef CREATE_TRACE_POINTS
> 
> (Just to prevent a bit more repeated boilerplate in each events definition
> file.)
> 
> This seems to work.  (Update: no it doesn't.  WTF has paravirt-trace.o got
> duplicate kmem tracepoints?!)

kmem was a PITA.  Looks like we might need to do a:

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

type of thing, and have each user define their own CREATE_FOO_TRACE_POINTS 
that they want to instantiate. This should be a requirement on any 
trace point header that is used in other headers.

Does just adding the above to the kmem.h header and your header fix it for 
you?

-- Steve




> 
> A related problem is that the TRACE_INCLUDE_FILE mechanism doesn't work,
> because if any tracepoint definition header sets it, it overrides the setting
> for all others, so, for example, arch/x86/include/asm/paravirt.h ends up being
> included as the source of definitions for events/sched.h.  I gave up and moved
> paravirt-trace.h to trace/events/pvops.h rather than try to deal with it.

Those that define TRACE_INCLUDE_FILE need to undef it too. :-/

> 
> Lucky for you Steven, none of this is getting any more pretty, so you may yet
> get your prize.

--
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/