linux-kernel - [PATCH 0/4] [GIT PULL] tracing: Harry Potter and the Deathly Macros

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-next>] [day] [month] [year] [list]

Date:	Fri, 03 Dec 2010 21:17:44 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	linux-kernel@...r.kernel.org
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Arjan van de Ven <arjan@...radead.org>,
	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Subject: [PATCH 0/4] [GIT PULL] tracing: Harry Potter and the Deathly Macros

Ingo,

This pull request is for 2.6.38.

The first two patches are boring and are just some updates for tracing.

But the second two patches are the Deathly Macros.

The first of the two is the Macro of Invisibility. Not really anything
to worry about. It adds the TP_CONDITION() which allows a tracepoint
to "hide" unwanted traces nicely. If the condition is not met, that
tracepoint will not be traced. Also, the "if" statement is outside
the fast path and is only hit during actual tracing (not there when
tracing is disabled).

The second patch is the Macro of Resurrection. It is resurrecting
the debate about stable tracepoints and if current tracepoints may change.
This patch uses the first patch to only trace the wakeup tracepoint
if it succeeds to actually wake something up. This makes the
"success" field in the tracepoint redundant and it seems silly to
keep it there. It wastes space in the buffers and adds a slight overhead
just to record it. But this wasted space is more of an issue than
the overhead.

Now if we change this, it may break tools that analyze the wakeup
tracepoint and checks the "success" field to know if it should
ignore it or not. Any tools that do this should have tested to
see if that field was there and if not assume the wakeup succeeded.

If we had the Macro of Invinicibility (true stable events), then
this would not be an issue for us. But unfortunately, the Macro of
Invincibility is not here, and is probably buried somewhere
with an old gay wizard.

Please pull the latest tip/perf/core tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
tip/perf/core

Steven Rostedt (3):
      tracing/events: Show real number in array fields
      tracing: Add TRACE_EVENT_CONDITIONAL()
      tracing: Only trace sched_wakeup if it actually work something up

Wu Zhangjin (1):
      ftrace: Speed up recordmcount

----
 include/linux/ftrace_event.h |    4 ++++
 include/linux/tracepoint.h   |   29 +++++++++++++++++++++++------
 include/trace/define_trace.h |   15 +++++++++++++++
 include/trace/events/sched.h |   16 ++++++++--------
 include/trace/ftrace.h       |   14 ++++++++++----
 kernel/trace/trace_events.c  |    6 ++++++
 kernel/trace/trace_export.c  |   14 ++++++++++----
 scripts/Makefile.build       |   13 +++++++++----
 8 files changed, 85 insertions(+), 26 deletions(-)

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