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]
Message-ID: <CAG2=9p96i-sD5=5ha3Sjo+76E0Tm-iztmLTmi0nd-VF9Lfo=tA@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ