From: Adrian Hunter <adrian.hunter@intel.com>
To: Namhyung Kim <namhyung@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Jiri Olsa <jolsa@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH] perf tools: Handle old data in PERF_RECORD_ATTR
Date: Mon, 14 Aug 2023 10:11:40 +0300 [thread overview]
Message-ID: <b2332dd5-e01e-dc61-e19c-55cf9a684ca2@intel.com> (raw)
In-Reply-To: <20230807061652.2492167-1-namhyung@kernel.org>
On 7/08/23 09:16, Namhyung Kim wrote:
> The PERF_RECORD_ATTR is used for a pipe mode to describe an event with
> attribute and IDs. The ID table comes after the attr and it calculate
> size of the table using the total record size and the attr size.
>
> n_ids = (total_record_size - end_of_the_attr_field) / sizeof(u64)
>
> This is fine for most use cases, but sometimes it saves the pipe output
> in a file and then process it later. And it becomes a problem if there
> is a change in attr size between the record and report.
>
> $ perf record -o- > perf-pipe.data # old version
> $ perf report -i- < perf-pipe.data # new version
>
> For example, if the attr size is 128 and it has 4 IDs, then it would
> save them in 168 byte like below:
>
> 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 },
> 128 byte: perf event attr { .size = 128, ... },
> 32 byte: event IDs [] = { 1234, 1235, 1236, 1237 },
>
> But when report later, it thinks the attr size is 136 then it only read
> the last 3 entries as ID.
>
> 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 },
> 136 byte: perf event attr { .size = 136, ... },
> 24 byte: event IDs [] = { 1235, 1236, 1237 }, // 1234 is missing
>
> So it should use the recorded version of the attr. The attr has the
> size field already then it should honor the size when reading data.
>
> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
> ---
> tools/perf/util/header.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
> index 52fbf526fe74..f89321cbfdee 100644
> --- a/tools/perf/util/header.c
> +++ b/tools/perf/util/header.c
> @@ -4381,7 +4381,8 @@ int perf_event__process_attr(struct perf_tool *tool __maybe_unused,
> union perf_event *event,
> struct evlist **pevlist)
> {
> - u32 i, ids, n_ids;
> + u32 i, n_ids;
> + u64 *ids;
> struct evsel *evsel;
> struct evlist *evlist = *pevlist;
>
> @@ -4397,9 +4398,8 @@ int perf_event__process_attr(struct perf_tool *tool __maybe_unused,
>
> evlist__add(evlist, evsel);
>
> - ids = event->header.size;
> - ids -= (void *)&event->attr.id - (void *)event;
> - n_ids = ids / sizeof(u64);
> + n_ids = event->header.size - sizeof(event->header) - event->attr.attr.size;
> + n_ids = n_ids / sizeof(u64);
> /*
> * We don't have the cpu and thread maps on the header, so
> * for allocating the perf_sample_id table we fake 1 cpu and
> @@ -4408,8 +4408,9 @@ int perf_event__process_attr(struct perf_tool *tool __maybe_unused,
> if (perf_evsel__alloc_id(&evsel->core, 1, n_ids))
> return -ENOMEM;
>
> + ids = (void *)&event->attr.attr + event->attr.attr.size;
> for (i = 0; i < n_ids; i++) {
> - perf_evlist__id_add(&evlist->core, &evsel->core, 0, i, event->attr.id[i]);
> + perf_evlist__id_add(&evlist->core, &evsel->core, 0, i, ids[i]);
> }
>
> return 0;
This is a good catch!
It looks like perf_event__hdr_swap() might also have this problem.
I wonder if we should remove 'id' from struct perf_record_header_attr
since the position is not guaranteed?
Probably could use a comment there either way.
Also perhaps a fixes tag and cc stable
next prev parent reply other threads:[~2023-08-14 7:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 6:16 [PATCH] perf tools: Handle old data in PERF_RECORD_ATTR Namhyung Kim
2023-08-10 20:56 ` Ian Rogers
2023-08-14 7:11 ` Adrian Hunter [this message]
2023-08-25 14:06 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b2332dd5-e01e-dc61-e19c-55cf9a684ca2@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).