[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM9d7cjDxNx42oxyL5A0TA+b6tJXtSgAP6eVvHOGwz55rZ7piw@mail.gmail.com>
Date: Wed, 11 May 2022 23:00:08 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Jiri Olsa <jolsa@...nel.org>, Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Ian Rogers <irogers@...gle.com>,
Song Liu <songliubraving@...com>, Hao Luo <haoluo@...gle.com>,
Milian Wolff <milian.wolff@...b.com>,
bpf <bpf@...r.kernel.org>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
Blake Jones <blakejones@...gle.com>
Subject: Re: [PATCH 1/4] perf report: Do not extend sample type of bpf-output event
Hi Arnaldo,
On Tue, May 10, 2022 at 9:50 AM Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
>
> Em Fri, May 06, 2022 at 01:16:24PM -0700, Namhyung Kim escreveu:
> > Currently evsel__new_idx() sets more sample_type bits when it finds a
> > BPF-output event. But it should honor what's recorded in the perf
> > data file rather than blindly sets the bits. Otherwise it could lead
> > to a parse error when it recorded with a modified sample_type.
>
> Can you please try to provide a Fixes: tag for this? This way reviewing
> gets simpler by looking at who introduced this, if there was some reason
> or if it was a plain oversight.
>
> It also helps to get this fix propabated to the stable trees.
Well.. actually this is not a fix. I've realized it adds some
sample types when it creates a new evsel regardless of
the perf_event_attr.
This was not a problem so far (as nobody touched it),
but when I changed some sample types during record
for this change, perf report sees a different value and
rejects the data.
Thanks,
namhyung
Powered by blists - more mailing lists