linux-kernel - Re: [RFC PATCH] perf: Handle multiple formatted AUX records

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]

Date:   Mon, 25 Jan 2021 11:25:17 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org, coresight@...ts.linaro.org,
        Ingo Molnar <mingo@...hat.com>, will@...nel.org,
        mark.rutland@....com, mike.leach@...aro.org, al.grant@....com,
        anshuman.khandual@....com, mathieu.poirier@...aro.org,
        linux-arm-kernel@...ts.infradead.org, jolsa@...hat.com,
        acme@...nel.org
Subject: Re: [RFC PATCH] perf: Handle multiple formatted AUX records

On Fri, Jan 22, 2021 at 03:18:29PM +0000, Suzuki K Poulose wrote:
> CoreSight PMU supports aux-buffer for the ETM tracing. The trace
> generated by the ETM (associated with individual CPUs, like Intel PT)
> is captured by a separate IP (CoreSight TMC-ETR/ETF until now).
> 
> The TMC-ETR applies formatting of the raw ETM trace data, as it
> can collect traces from multiple ETMs, with the TraceID to indicate
> the source of a given trace packet.
> 
> Arm Trace Buffer Extension is new "sink" IP, attached to individual
> CPUs and thus do not provide additional formatting, like TMC-ETR.
> 
> Additionally, a system could have both TRBE *and* TMC-ETR for
> the trace collection. e.g, TMC-ETR could be used as a single
> trace buffer to collect data from multiple ETMs to correlate
> the traces from different CPUs. It is possible to have a
> perf session where some events end up collecting the trace
> in TMC-ETR while the others in TRBE. Thus we need a way
> to identify the type of the trace for each AUX record.
> 
> This patch adds a new flag to indicate the trace format
> for the given record. Also, includes the changes that
> demonstrates how this can be used in the CoreSight PMU
> to solve the problem.
> 
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@....com>
> ---

> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index b15e3447cd9f..ea7dcc7b30f0 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -1109,6 +1109,7 @@ enum perf_callchain_context {
>  #define PERF_AUX_FLAG_OVERWRITE		0x02	/* snapshot from overwrite mode */
>  #define PERF_AUX_FLAG_PARTIAL		0x04	/* record contains gaps */
>  #define PERF_AUX_FLAG_COLLISION		0x08	/* sample collided with another */
> +#define PERF_AUX_FLAG_ALT_FMT		0x10	/* this record is in alternate trace format */

Since we have a whole u64, do we want to reserve a whole nibble (or
maybe even a byte) for a format type? Because with a single bit like
this, we'll kick ourselves when we end up with the need for a 3rd format
type.