linux-kernel - [PATCH v1 0/6] perf: Add AUX data sampling

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]

Message-Id: <20180612075117.65420-1-alexander.shishkin@linux.intel.com>
Date:   Tue, 12 Jun 2018 10:51:11 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Ingo Molnar <mingo@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...hat.com>,
        linux-kernel@...r.kernel.org, jolsa@...hat.com,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: [PATCH v1 0/6] perf: Add AUX data sampling

Hi,

This series introduces AUX data sampling for perf events, which in
case of our instruction/branch tracing PMUs like Intel PT, BTS, CS
ETM means execution flow history leading up to a perf event's
overflow.

In case of Intel PT, this can be used as an alternative to LBR, with
virtually as many as you like branches per sample. It doesn't support
some of the LBR features (branch prediction indication, basic block
level timing, etc [1]) and it can't be exposed as BRANCH_STACK, because
that would require decoding PT stream in kernel space, which is not
practical. Instead, we deliver the PT data to userspace as is, for
offline processing. The PT decoder already supports presenting PT as
virtual LBR.

AUX sampling is different from the snapshot mode in that it doesn't
require instrumentation (for when to take a snapshot) and is better
for generic data collection, when you don't yet know what you are
looking for. It's also useful for automated data collection, for
example, for feedback-driven compiler optimizaitions.

It's also different from the "full trace mode" in that it produces
much less data and, consequently, takes up less I/O bandwidth and
storage space, and takes less time to decode.

The bulk of code is in 4/6, which adds the user interface bits and
adds code to measure and copy out AUX data. 1/6 and 2/6 close the
races around the sampling code, 3/6 is a helper, 5/6 kills the
PERF_FLAG_FD_OUTPUT which has been effectively dead for about 8 years
now and 6/6 allows SET_OUTPUT between SW and HW contexts, which allows
the tool to not carry around additional file descriptors when sampling
a hardware event.

I'm not including the tooling patches, which Adrian will post separately.
Meanwhile, they can be found here [2].

Changes since the last time I posted patches to this effect [3]:
 - instead of creating kernel events with AUX data, have the user create
   them and pass on to the events that they wish to see AUX samples on;
 - as a result, dropped most of the code.

[1] https://marc.info/?l=linux-kernel&m=147467007714928&w=2
[2] https://git.kernel.org/cgit/linux/kernel/git/ash/linux.git/log/?h=perf-aux-sampling
[3] https://marc.info/?l=linux-kernel&m=147463007105836

Adrian Hunter (1):
  perf: Allow set-output for task contexts of different types

Alexander Shishkin (5):
  perf: Disable PMU around address filter adjustment
  perf: Disable IRQs in address filter sync path
  perf: Add an iterator for AUX data
  perf: Allow using AUX data in perf samples
  perf: Drop PERF_FLAG_FD_OUTPUT

 include/linux/perf_event.h      |  10 ++
 include/uapi/linux/perf_event.h |   8 +-
 kernel/events/core.c            | 206 +++++++++++++++++++++++++++++---
 kernel/events/internal.h        |   5 +
 kernel/events/ring_buffer.c     |  34 ++++++
 5 files changed, 247 insertions(+), 16 deletions(-)

-- 
2.17.1