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: <20140213102552.2b292484@gandalf.local.home>
Date:	Thu, 13 Feb 2014 10:25:52 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
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 Thu, 13 Feb 2014 15:26:42 +0100
Frederic Weisbecker <fweisbec@...il.com> wrote:

> > Is this worth doing?
> 
> It sounds worth yeah. I've run into this situation multiple times where I had

Is it?

> to pass 0 instead of nothing on a tracepoint.

What tracepoints?

The problem I have with a tracepoint that does not pass any information
what's so ever, is that it can be too tempting to use. Tracepoints do
not have zero overhead when not used, but a negligible one. Too many
tracepoints add up, and their foot print can start to be noticed.

Point being, why have a tracepoint if you are not recording any data?
Just do a function trace, or add a kprobe. That's easy enough.

But that said, see below.

> 
> Now about the name, why not TRACE_EVENT_EMPTY?

Because that's an ugly name ;-)

Also a bit misleading, because it sounds like the there's no items
attached or something. It is too close to "list_empty()". My original
name was TRACE_EVENT_NOARGS(), which could work too.

Now another possible solution is to just introduce a trace_marker()
function that you could place anywhere. And then they could show up in
trace/events/markers/file-func-line/

We could do something like:

struct trace_marker {
	char *file;
	char *func;
	int line;
	struct static_key key;
};

#define trace_marker() __trace_marker(__FILE__,__func__, __LINE__)
static inline void __trace_marker(const char *file,
				const char *func, int line)
{
	static struct trace_marker marker
		__attribute__((section("__trace_marker"))) = {
		.file = file,
		.func = func,
		.line = line
	};

	if (static_key_false(&marker.key))
		trace_marker_call(&marker);
}

As marker would be a static value, gcc should hard code the first
parameter to it and make the call. Basically something like:

	mov $0x<marker-address>, %rdi
	call trace_marker_call

If we really want to be efficient, we could extend jump labels for each
arch, and remove the call completely.

	asm goto ("1:"
		  ".byte NOP\n"
		  ".pushsection __trace_marker_struct\n"
		  "2:.quad 1b\n"
		  ".quad %file\n"
		  ".quad %func\n'
		  ".word %line\n"
		  ".popsection\n"
		  ".pushsection __trace_marker_ptrs\n"
		  ".quad 2b\n"
		  ".popsection\n"
		 : : file, func, line);

[ OK, I didn't follow the true format for asm syntax, but that's
because I'm just trying to relay an idea, not actually make working
code ]

Then the only thing that would be inserted in the code is a nop. We
could then replace that nop with a call to a trampoline (similar to
mcount) that can call a C function with the address that it came from
so that the function could do a look up to find the matching marker to
trace.

OK, this is probably a bit too much, but it is feasible. Most likely
not worth the pain.

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