linux-kernel - Re: TRACE_EVENT without ARGS

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1348244077.13080.84.camel@gandalf.local.home>
Date:	Fri, 21 Sep 2012 12:14:37 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Wolfgang Grandegger <wg@...ndegger.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: TRACE_EVENT without ARGS

On Fri, 2012-09-21 at 17:35 +0200, Wolfgang Grandegger wrote:
> Hello,
> 
> I would like to define trace events for functions without arguments,
> e.g. my_yield(). But TRACE_EVENT requires at least one argument to be
> defined and I also have not found an example in the kernel sources,
> apart from:
> 
>   $ cat include/trace/events/xen.h
>   ...
>   TRACE_EVENT(xen_mmu_flush_tlb,
>               TP_PROTO(int x),
>               TP_ARGS(x),
>               TP_STRUCT__entry(__array(char, x, 0)),
>               TP_fast_assign((void)x),
>               TP_printk("%s", "")
>           );
> 
> It uses a dummy argument to work around the problem. Is that the
> recommended way to handle such cases?
> 

Right now this is the only way, because honestly, I was trying to avoid
people from doing this. I'm more worried about people littering the
kernel with these place markers, which give nothing but "I'm hit here".
It would be better to have a 'noinline' to the xen_flush_tlb() call, and
use function tracer to trace it:

	echo xen_flush_tlb > debug/tracing/set_ftrace_filter

But seeing that this just throws in a dummy argument, this doesn't make
things nicer. My worry is about bloat. Each TRACE_EVENT() can add up to
5k to the kernel. When you use the DECLARE_EVENT_CLASS() along with
DEFINE_EVENT(), most of that goes into the DECLARE_EVENT_CLASS, and each
DEFINE_EVENT() adds just about 250 bytes. This is why I push people to
use DEFINE_EVENT, as TRACE_EVENT() is really nothing more than:

#define TRACE_EVENT(...) \
	DECLARE_EVENT_CLASS(..) \
	DEFINE_EVENT(...)

Now maybe I can add something called:

TRACE_MARKER(name);

Where this will create an event that has no fields, and you call this
with: trace_name() and no parameters.

This way, I could probably hack something up that this will be much
smaller, and leave out the creation of fields and related code.

Heck, as it is saving no data, I could make it use a default trace and
perf function that does nothing but state that it was hit.

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