linux-kernel - [RFC PATCH 0/3] Integration of trace events with System Trace IP blocks

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

Date:	Fri, 5 Jun 2015 13:37:00 +0800
From:	Chunyan Zhang <zhang.chunyan@...aro.org>
To:	Steven Rostedt <rostedt@...dmis.org>, mingo@...hat.com
Cc:	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Kaixu Xia <kaixu.xia@...aro.org>,
	Serge Broslavsky <serge.broslavsky@...aro.org>,
	Mark Brown <broonie@...aro.org>,
	alexander.shishkin@...ux.intel.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: [RFC PATCH 0/3] Integration of trace events with System Trace IP blocks

IP blocks allowing a variety of trace sources to log debugging
information to a pre-defined area have been introduced on a couple of
architecture [1][2]. These system trace blocks (also known as STM)
typically follow the MIPI STPv2 protocol [3] and provide a system wide
logging facility to any device, running a kernel or not, with access
to the block's log entry port(s).  Since each trace message has a
timestamp is it possible to correlate events happening in the entire
system rather than being confined to the logging facility of a single
entity.

This patch is using a very simple "stm_source" introduced in [2] to
duplicate the output of the trace event subsystem to an STM, in this
case coresight STM.  That way logging information generated by the
trace event subsystem and gathered in the coresight sink can be used
in conjunction with trace data from other board components, also
collected in the same trace sink.  This example is using coresight but
the same would apply to any architecture wishing to do the same.

The goal of this RFC is to solicit comments on the method used to
connect trace event logging with STMs (using the generic STM API)
rather than function "stm_ftrace_write()" itself, which was provided
for completeness of the proof of concept only.

I'm eager to see your comments on this, and if you have some good
ideas that can slow down the overhead, please let me know.

Regards,
Chunyan

[1]. https://lkml.org/lkml/2015/2/4/729
[2]. http://comments.gmane.org/gmane.linux.kernel/1914526
[3]. http://mipi.org/specifications/debug#STP

Chunyan Zhang (2):
  Trace log handler for logging into STM blocks
  Introduce trace log output function for STM

Mathieu Poirier (1):
  STM trace event: Adding generic buffer interface driver

 drivers/stm/Kconfig             | 11 +++++
 drivers/stm/Makefile            |  2 +
 drivers/stm/stm_trace_event.c   | 46 +++++++++++++++++++
 include/linux/ftrace_event.h    | 15 +++++++
 include/trace/ftrace.h          | 47 +++++++++++++++++++
 kernel/trace/Makefile           |  1 +
 kernel/trace/trace_output_stm.c | 99 +++++++++++++++++++++++++++++++++++++++++
 7 files changed, 221 insertions(+)
 create mode 100644 drivers/stm/stm_trace_event.c
 create mode 100644 kernel/trace/trace_output_stm.c

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