All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Like Xu <like.xu.linux@gmail.com>
Cc: 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@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] perf/x86/intel: Fix PEBS-via-PT reload base value for Extended PEBS
Date: Tue, 22 Jun 2021 15:36:03 +0200	[thread overview]
Message-ID: <YNHnQzECTcFGOoHO@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210621034710.31107-1-likexu@tencent.com>

On Mon, Jun 21, 2021 at 11:47:10AM +0800, Like Xu wrote:
> If we use the "PEBS-via-PT" feature on a platform that supports
> extended PBES, like this:
> 
>     perf record -c 10000 \
>     -e '{intel_pt/branch=0/,branch-instructions/aux-output/p}' uname
> 
> we will encounter the following call trace:
> 
> [  250.906542] unchecked MSR access error: WRMSR to 0x14e1 (tried to write
> 0x0000000000000000) at rIP: 0xffffffff88073624 (native_write_msr+0x4/0x20)
> [  250.920779] Call Trace:
> [  250.923508]  intel_pmu_pebs_enable+0x12c/0x190
> [  250.928359]  intel_pmu_enable_event+0x346/0x390
> [  250.933300]  x86_pmu_start+0x64/0x80
> [  250.937231]  x86_pmu_enable+0x16a/0x2f0
> [  250.941434]  perf_event_exec+0x144/0x4c0
> [  250.945731]  begin_new_exec+0x650/0xbf0
> [  250.949933]  load_elf_binary+0x13e/0x1700
> [  250.954321]  ? lock_acquire+0xc2/0x390
> [  250.958430]  ? bprm_execve+0x34f/0x8a0
> [  250.962544]  ? lock_is_held_type+0xa7/0x120
> [  250.967118]  ? find_held_lock+0x32/0x90
> [  250.971321]  ? sched_clock_cpu+0xc/0xb0
> [  250.975527]  bprm_execve+0x33d/0x8a0
> [  250.979452]  do_execveat_common.isra.0+0x161/0x1d0
> [  250.984673]  __x64_sys_execve+0x33/0x40
> [  250.988877]  do_syscall_64+0x3d/0x80
> [  250.992806]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [  250.998302] RIP: 0033:0x7fbc971d82fb
> [  251.002235] Code: Unable to access opcode bytes at RIP 0x7fbc971d82d1.
> [  251.009303] RSP: 002b:00007fffb8aed808 EFLAGS: 00000202 ORIG_RAX: 000000000000003b
> [  251.017478] RAX: ffffffffffffffda RBX: 00007fffb8af2f00 RCX: 00007fbc971d82fb
> [  251.025187] RDX: 00005574792aac50 RSI: 00007fffb8af2f00 RDI: 00007fffb8aed810
> [  251.032901] RBP: 00007fffb8aed970 R08: 0000000000000020 R09: 00007fbc9725c8b0
> [  251.040613] R10: 6d6c61632f6d6f63 R11: 0000000000000202 R12: 00005574792aac50
> [  251.048327] R13: 00007fffb8af35f0 R14: 00005574792aafdf R15: 00005574792aafe7
> 
> This is because the target reload msr address is calculated
> based on the wrong base msr and the target reload msr value
> is accessed from ds->pebs_event_reset[] with the wrong offset.
> 
> According to Intel SDM Table 2-14, for extended PBES feature,
> the reload msr for MSR_IA32_FIXED_CTRx should be based on
> MSR_RELOAD_FIXED_CTRx.
> 
> For fixed counters, let's fix it by overriding the reload msr
> address and its value, thus avoiding out-of-bounds access.
> 
> Fixes: 42880f726c66("perf/x86/intel: Support PEBS output to PT")
> Signed-off-by: Like Xu <likexu@tencent.com>

Thanks!

  reply	other threads:[~2021-06-22 13:36 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21  3:47 [RESEND PATCH] perf/x86/intel: Fix PEBS-via-PT reload base value for Extended PEBS Like Xu
2021-06-22 13:36 ` Peter Zijlstra [this message]
2021-06-24  7:09 ` [tip: perf/core] " tip-bot2 for Like Xu

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=YNHnQzECTcFGOoHO@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=like.xu.linux@gmail.com \
    --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=tglx@linutronix.de \
    --cc=x86@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.