From: Peter Zijlstra <peterz@infradead.org>
To: kan.liang@linux.intel.com
Cc: acme@kernel.org, mingo@kernel.org, linux-kernel@vger.kernel.org,
eranian@google.com, namhyung@kernel.org, jolsa@redhat.com,
ak@linux.intel.com, yao.jin@linux.intel.com, mpe@ellerman.id.au,
maddy@linux.vnet.ibm.com
Subject: Re: [PATCH V2 3/5] perf/x86/intel: Filter unsupported Topdown metrics event
Date: Wed, 27 Jan 2021 20:13:40 +0100 [thread overview]
Message-ID: <YBG7ZJUBQsUmoXlY@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <1611761925-159055-4-git-send-email-kan.liang@linux.intel.com>
On Wed, Jan 27, 2021 at 07:38:43AM -0800, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> Current perf doesn't check the index of a Topdown metrics event before
> updating the event. A perf tool user may get a value from an unsupported
> Topdown metrics event.
>
> For example, the L2 topdown event, cpu/event=0x00,umask=0x84/, is not
> supported on Ice Lake. A perf tool user may mistakenly use the
> unsupported events via RAW format. In this case, the scheduler follows
> the unknown event handling and assigns a GP counter to the event. The
> icl_get_topdown_value() returns the value of the slots to the event.
> The perf tool user will get the value for the unsupported
> Topdown metrics event.
>
> Add a check in the __icl_update_topdown_event() and avoid updating
> unsupported events.
I was struggling trying to understand how we end up here. Because
userspace can add whatever crap it wants, and why is only this thing a
problem..
But the actual problem is the next patch changing INTEL_TD_METRIC_NUM,
which then means is_metric_idx() will change, and that means that for
ICL we'll accept these raw events as metric events on creation and then
at runtime we get into trouble.
This isn't spelled out.
I do think this is entirely the wrong fix for that though. You're now
adding cycles to the relative hot path, instead of fixing the problem at
event creation, which is the slow path.
Why can't we either refuse the event on ICL or otherwise wreck it on
construction to avoid getting into trouble here?
> Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
> ---
> arch/x86/events/intel/core.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
> index 8eba41b..b02d482 100644
> --- a/arch/x86/events/intel/core.c
> +++ b/arch/x86/events/intel/core.c
> @@ -2319,6 +2319,17 @@ static void __icl_update_topdown_event(struct perf_event *event,
> {
> u64 delta, last = 0;
>
> + /*
> + * Although the unsupported topdown events are not exposed to users,
> + * users may mistakenly use the unsupported events via RAW format.
> + * For example, using L2 topdown event, cpu/event=0x00,umask=0x84/,
> + * on Ice Lake. In this case, the scheduler follows the unknown
> + * event handling and assigns a GP counter to the event.
> + * Check the case, and avoid updating unsupported events.
> + */
> + if (event->hw.idx < INTEL_PMC_IDX_FIXED)
> + return;
> +
> delta = icl_get_topdown_value(event, slots, metrics);
> if (last_slots)
> last = icl_get_topdown_value(event, last_slots, last_metrics);
> --
> 2.7.4
>
next prev parent reply other threads:[~2021-01-27 19:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-27 15:38 [PATCH V2 0/5] perf core PMU support for Sapphire Rapids (Kernel) kan.liang
2021-01-27 15:38 ` [PATCH V2 1/5] perf/core: Add PERF_SAMPLE_WEIGHT_STRUCT kan.liang
2021-01-27 19:03 ` Peter Zijlstra
2021-01-27 21:54 ` Liang, Kan
2021-01-27 15:38 ` [PATCH V2 2/5] perf/x86/intel: Factor out intel_update_topdown_event() kan.liang
2021-01-27 15:38 ` [PATCH V2 3/5] perf/x86/intel: Filter unsupported Topdown metrics event kan.liang
2021-01-27 19:13 ` Peter Zijlstra [this message]
2021-01-27 20:50 ` Liang, Kan
2021-01-27 15:38 ` [PATCH V2 4/5] perf/x86/intel: Add perf core PMU support for Sapphire Rapids kan.liang
2021-01-27 15:38 ` [PATCH V2 5/5] perf/x86/intel: Support CPUID 10.ECX to disable fixed counters kan.liang
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=YBG7ZJUBQsUmoXlY@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maddy@linux.vnet.ibm.com \
--cc=mingo@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=yao.jin@linux.intel.com \
/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