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 18:06:03 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Steven Rostedt <rostedt@...dmis.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

Steven Rostedt wrote:
> 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
>   

The sched and irq tracepoints have the same general problem.

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

No, I have a complete patch to do what I'm proposing here, and kmem went 
ahead and failed anyway.  I'll post a cleaned up set of RFC patches and 
try to track down what's happening later.

And there seems to be a secondary problem with kmem tracepoints being 
called without an explicit #include of <trace/events/kmem.h>, so I'm 
seeing compiler errors relating to that too:

  CC      arch/x86/kernel/paravirt-trace.o
In file included from /home/jeremy/git/linux/include/linux/slab.h:165,
                 from /home/jeremy/git/linux/include/linux/percpu.h:6,
                 from /home/jeremy/git/linux/include/linux/vmstat.h:6,
                 from /home/jeremy/git/linux/include/linux/mm.h:596,
                 from /home/jeremy/git/linux/include/linux/ring_buffer.h:6,
                 from /home/jeremy/git/linux/include/linux/ftrace_event.h:6,
                 from /home/jeremy/git/linux/include/trace/ftrace.h:20,
                 from /home/jeremy/git/linux/include/trace/define_trace.h:64,
                 from /home/jeremy/git/linux/include/trace/instantiate_trace.h:7,
                 from /home/jeremy/git/linux/include/trace/events/pvops.h:1186,
                 from /home/jeremy/git/linux/arch/x86/kernel/paravirt-trace.c:5:
/home/jeremy/git/linux/include/linux/slab_def.h: In function 'kmalloc':
/home/jeremy/git/linux/include/linux/slab_def.h:157: error: implicit declaration of function 'trace_kmalloc'


Also, the pvops trace stuff adds quite a lot of overhead to the kernel 
size - and probably runtime - so I think we'll need to have Kconfig 
switches for each set of trace events rather than a single fat 
CONFIG_TRACEPOINTS switch.

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