From: Rob Herring <robh@kernel.org>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, James Clark <james.clark@arm.com>,
linux-perf-users <linux-perf-users@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] perf: Ignore format attributes with an unknown perf_event_attr field
Date: Fri, 9 Sep 2022 15:11:20 -0500 [thread overview]
Message-ID: <CAL_Jsq+CH13TASeAb5VMa=hXGyAT4bDdGeS2XJj9ym6_WM4HRw@mail.gmail.com> (raw)
In-Reply-To: <CAM9d7ci0Dn3hAX9dp1UMGK7SN-w1BoRqQz6hk8Oykfaa=LnWwg@mail.gmail.com>
On Tue, Sep 6, 2022 at 1:16 PM Namhyung Kim <namhyung@kernel.org> wrote:
>
> On Fri, Sep 2, 2022 at 8:25 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Fri, Sep 2, 2022 at 1:53 AM Namhyung Kim <namhyung@kernel.org> wrote:
> > >
> > > Hello,
> > >
> > > On Thu, Sep 1, 2022 at 11:55 AM Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > If the kernel exposes a new perf_event_attr field in a format attr, perf
> > > > will return an error stating the specified PMU can't be found. For
> > > > example, a format attr with 'config3:0-63' causes an error if config3 is
> > > > unknown to perf. This causes a compatibility issue between a newer
> > > > kernel and an older perf tool.
> > > >
> > > > The addition here makes any attr string up to the ':' ignored, but
> > > > still checks the 'bits' portion.
> > > >
> > > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > > ---
> > > > This is the YACC mud I threw and seems to stick. Maybe there's a better
> > > > way to handle this. It doesn't seem like there's a way to do wildcards
> > > > (i.e. config.*) in YACC.
> > > >
> > > > This is needed for this series[1]. Unfortunately the best we do to avoid
> > > > the issue is applying this to stable. I think there's some time before
> > > > v8.7 h/w is deployed, too.
> > >
> > > Maybe you could change the format_term rule to take an identifier instead
> > > of PP_CONFIG* directly and pass it to perf_pmu__new_format(). Then
> > > it could check the string and create an appropriate PERF_PMU_FORMAT_VALUE_*
> > > or ignore it according to the PERF_ATTR_SIZE_VER*.
> >
> > That only moves parsing of configN from YACC to strcmp in C. In doing
> > so, we'd be left with just the 'error' token case which seems a bit
> > odd (if there's another way to do it, I don't know. yacc is not my
> > thing). Is that really better?
>
> I thought we could do more flexible handling and detailed error reporting
> in the C code. But it could be done in the lex/yacc as well..
>
> I think the general idea is that we want to run a more recent version of
> perf tools than the kernel. So if it detects the tool is older, it can show
> a warning message like:
>
> "config3 is not in the perf_event_attr.. skipping.
> Maybe you're running on a newer kernel. Please upgrade the perf tool."
I figured out how to simplify the yacc code and add a warning.
However, one thing to note is that we'll always get the warning if any
PMU has an unsupported format attr because all the PMUs are scanned.
For example, just this gives a warning even though the SPE PMU is not
used:
perf record -e cycles -- true
So the warning might be misleading. On the flip side, new additions are rare.
Rob
next prev parent reply other threads:[~2022-09-09 20:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-01 18:47 [PATCH] perf: Ignore format attributes with an unknown perf_event_attr field Rob Herring
2022-09-01 19:22 ` Arnaldo Carvalho de Melo
2022-09-01 19:28 ` Rob Herring
2022-09-02 6:52 ` Namhyung Kim
2022-09-02 15:25 ` Rob Herring
2022-09-06 18:15 ` Namhyung Kim
2022-09-09 20:11 ` Rob Herring [this message]
2022-09-09 20:30 ` 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='CAL_Jsq+CH13TASeAb5VMa=hXGyAT4bDdGeS2XJj9ym6_WM4HRw@mail.gmail.com' \
--to=robh@kernel.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--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).