linux-kernel - Re: [RFC - beta][PATCH] tracing: Introduce 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: <20140213142640.GD14383@localhost.localdomain>
Date:	Thu, 13 Feb 2014 15:26:42 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Berg <johannes@...solutions.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Wolfgang Grandegger <wg@...ndegger.com>
Subject: Re: [RFC - beta][PATCH] tracing: Introduce TRACE_MARKER() no
 argument trace event

On Fri, Feb 07, 2014 at 11:23:57AM -0500, Steven Rostedt wrote:
> A while back ago, Wolfgang (and others) have asked about the ability to
> add a trace event that recorder no data other than the fact that the
> trace event was hit.
> 
> I've been reluctant to do so, but I noticed that one already exists in
> the iwlwifi tracepoints (iwlwifi_dev_irq) where it does a wasteful:
> 
>         /* TP_printk("") doesn't compile */
>         TP_printk("%d", 0)
> 
> The reason this is wasteful, is that there's a lot of code generated by
> the TRACE_EVENT() macros that end up basically being nops.
> 
> I figured I would instead create a TRACE_MARKER(name, print) that would
> be something like:
> 
> Added to tracepoint header:
> 
>  TRACE_MARKER(tpname, "Show this message");
> 
> Then you have:
> 
> 	trace_tpname();
> 
> in the code.
> 
> Notice that the tracepoint function (trace_<name>()) has no arguments.
> That's because the message is stored in the tracepoint (in one place)
> and is printed when the tracepoint is read. That is, the message isn't
> even recorded in the ring buffer.
> 
> It still shows up in the tracepoint format file:
> 
> name: tpname
> ID: 281
> format:
> 	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
> 	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
> 	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
> 	field:int common_pid;	offset:4;	size:4;	signed:1;
> 
> 
> print fmt: "Show this message"
> 
> The TRACE_MARKER() is basically an optimized version of TRACE_EVENT()
> with no arguments. It can be enabled and disabled the same way as any
> other event, and stays within the system it was created in.
> 
> Is this worth doing?

It sounds worth yeah. I've run into this situation multiple times where I had
to pass 0 instead of nothing on a tracepoint.

Now about the name, why not TRACE_EVENT_EMPTY?

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