From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>, Andi Kleen <ak@linux.intel.com>,
Kan Liang <kan.liang@intel.com>,
lkml <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Andi Kleen <andi@firstfloor.org>,
Michael Petlan <mpetlan@redhat.com>
Subject: Re: [PATCH] Revert "perf tools: Fix PMU term format max value calculation"
Date: Tue, 9 Oct 2018 10:52:26 -0300 [thread overview]
Message-ID: <20181009135226.GC10775@kernel.org> (raw)
In-Reply-To: <20181009095917.GE6499@krava>
Em Tue, Oct 09, 2018 at 11:59:17AM +0200, Jiri Olsa escreveu:
> ping
oops, applied to perf/urgent, added a Fixes: line so that stable@ pick
this up.
- Arnaldo
> thanks,
> jirka
>
> On Wed, Oct 03, 2018 at 09:20:46AM +0200, Jiri Olsa wrote:
> > This reverts commit ac0e2cd555373ae6f8f3a3ad3fbbf5b6d1e7aaaa.
> >
> > Michael reported an issue with oversized terms values assignment
> > and I noticed there was actually a misunderstanding of the max
> > value check in the past.
> >
> > The above commit's changelog says:
> >
> > If bit 21 is set, there is parsing issues as below.
> >
> > $ perf stat -a -e uncore_qpi_0/event=0x200002,umask=0x8/
> > event syntax error: '..pi_0/event=0x200002,umask=0x8/'
> > \___ value too big for format, maximum is 511
> >
> > But there's no issue there, because the event value is distributed
> > along the value defined by the format. Even if the format defines
> > separated bit, the value is treated as a continual number, which
> > should follow the format definition.
> >
> > In above case it's 9-bit value with last bit separated:
> > $ cat uncore_qpi_0/format/event
> > config:0-7,21
> >
> > Hence the value 0x200002 is correctly reported as format violation,
> > because it exceeds 9 bits. It should have been 0x102 instead, which
> > sets the 9th bit - the bit 21 of the format.
> >
> > $ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/
> > Using CPUID GenuineIntel-6-2D
> > ...
> > ------------------------------------------------------------
> > perf_event_attr:
> > type 10
> > size 112
> > config 0x200802
> > sample_type IDENTIFIER
> > ...
> >
> > Cc: Andi Kleen <ak@linux.intel.com>
> > Cc: Kan Liang <kan.liang@intel.com>
> > Reported-by: Michael Petlan <mpetlan@redhat.com>
> > Link: http://lkml.kernel.org/n/tip-icxq7a1r66lusm3ahaimekis@git.kernel.org
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > tools/perf/util/pmu.c | 13 +++++++------
> > 1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
> > index afd68524ffa9..7799788f662f 100644
> > --- a/tools/perf/util/pmu.c
> > +++ b/tools/perf/util/pmu.c
> > @@ -930,13 +930,14 @@ static void pmu_format_value(unsigned long *format, __u64 value, __u64 *v,
> >
> > static __u64 pmu_format_max_value(const unsigned long *format)
> > {
> > - __u64 w = 0;
> > - int fbit;
> > -
> > - for_each_set_bit(fbit, format, PERF_PMU_FORMAT_BITS)
> > - w |= (1ULL << fbit);
> > + int w;
> >
> > - return w;
> > + w = bitmap_weight(format, PERF_PMU_FORMAT_BITS);
> > + if (!w)
> > + return 0;
> > + if (w < 64)
> > + return (1ULL << w) - 1;
> > + return -1;
> > }
> >
> > /*
> > --
> > 2.17.1
> >
next prev parent reply other threads:[~2018-10-09 13:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-03 7:20 [PATCH] Revert "perf tools: Fix PMU term format max value calculation" Jiri Olsa
2018-10-03 14:34 ` [RFC] perf tools: Wrong filter_band* values in json calculation" Jiri Olsa
2018-10-03 14:45 ` Andi Kleen
2018-10-09 10:01 ` Jiri Olsa
2018-10-09 21:18 ` Andi Kleen
2018-10-10 8:03 ` [PATCH] perf tools: Fix wrong filter_band* values for uncore events Jiri Olsa
2018-10-10 12:58 ` Arnaldo Carvalho de Melo
2018-10-18 6:17 ` [tip:perf/urgent] perf vendor events intel: " tip-bot for Jiri Olsa
2018-10-09 9:59 ` [PATCH] Revert "perf tools: Fix PMU term format max value calculation" Jiri Olsa
2018-10-09 13:52 ` Arnaldo Carvalho de Melo [this message]
2018-10-18 6:17 ` [tip:perf/urgent] " tip-bot for Jiri Olsa
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=20181009135226.GC10775@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andi@firstfloor.org \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=mpetlan@redhat.com \
--cc=namhyung@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.