linux-kernel - Re: [PATCH 0/1] Support PERF_SAMPLE_READ with inherit

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: Fri, 19 Jan 2024 18:08:52 +0000
From: Ben Gainey <Ben.Gainey@....com>
To: "ak@...ux.intel.com" <ak@...ux.intel.com>
CC: "irogers@...gle.com" <irogers@...gle.com>,
	"alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
	James Clark <James.Clark@....com>, "peterz@...radead.org"
	<peterz@...radead.org>, Mark Rutland <Mark.Rutland@....com>,
	"linux-perf-users@...r.kernel.org" <linux-perf-users@...r.kernel.org>,
	"mingo@...hat.com" <mingo@...hat.com>, "acme@...nel.org" <acme@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"jolsa@...nel.org" <jolsa@...nel.org>, "namhyung@...nel.org"
	<namhyung@...nel.org>, "adrian.hunter@...el.com" <adrian.hunter@...el.com>
Subject: Re: [PATCH 0/1] Support PERF_SAMPLE_READ with inherit_stat

On Fri, 2024-01-19 at 09:45 -0800, Andi Kleen wrote:
> Ben Gainey <ben.gainey@....com> writes:
>
> > In this configuration stream ids (such as may appear in the
> > read_format
> > field of a PERF_RECORD_SAMPLE) are no longer globally unique,
> > rather
> > the pair of (stream id, tid) uniquely identify each event. Tools
> > that
> > rely on this, for example to calculate a delta between samples,
> > would
> > need updating to take this into account. Previously valid event
> > configurations (system-wide, no-inherit and so on) where each
> > stream id
> > is the identifier are unaffected.
>
> So is this an ABI break? It might need an optin, if it breaks
> anything,
> which wouldn't surprise me. We do have a lot of different perf stream
> parsers around these days and we cannot break them.
>
> -Andi

I had considered that, but given currently this perf_event_attr
configuration is not allowed, I assumed that it would require existing
tools to add support which would in effect be an opt-in. Of course,
adding a new flag to be explicit would be trivial enough if required.

That said, the binary format for the mmap records / read() etc does not
change so using an unmodified tool to parse the data file will give bad
results. Therefore any workflow where "modified recording tool" can be
combined with "older / unmodified parsing tool" will break. Not sure of
the best way to handle this... presumably whenever a change is made to
the perf record format, any workflow that allows old parsers to read
new format data without version checks could fail? Admittedly this is a
"looks the same but isn't" change so harder for tools devs to spot. Any
suggestions?

For the perf tools, is there a means to record in perf.data a minimum
supported tool version / feature incompatibility flags?

Regards
Ben
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.