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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ