From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Anton Blanchard <anton@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>
Subject: [PATCH 3.10 10/14] powerpc/perf: Fix book3s kernel to userspace backtraces
Date: Wed, 8 Jul 2015 00:31:50 -0700 [thread overview]
Message-ID: <20150708073102.764578543@linuxfoundation.org> (raw)
In-Reply-To: <20150708073102.284623533@linuxfoundation.org>
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Blanchard <anton@samba.org>
commit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream.
When we take a PMU exception or a software event we call
perf_read_regs(). This overloads regs->result with a boolean that
describes if we should use the sampled instruction address register
(SIAR) or the regs.
If the exception is in kernel, we start with the kernel regs and
backtrace through the kernel stack. At this point we switch to the
userspace regs and backtrace the user stack with perf_callchain_user().
Unfortunately these regs have not got the perf_read_regs() treatment,
so regs->result could be anything. If it is non zero,
perf_instruction_pointer() decides to use the SIAR, and we get issues
like this:
0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--52.35%-- 0
| |
| |--46.39%-- __hrtimer_start_range_ns
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | |
| | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
| | | |
| | | --100.00%-- 0x7e714
| | | 0x7e714
Notice the bogus _raw_spin_irqsave when we transition from kernel
(system_call) to userspace (0x7e714). We inserted what was in the SIAR.
Add a check in regs_use_siar() to check that the regs in question
are from a PMU exception. With this fix the backtrace makes sense:
0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave
|
---_raw_spin_lock_irqsave
|
|--53.83%-- 0
| |
| |--44.73%-- hrtimer_try_to_cancel
| | kvmppc_start_thread
| | kvmppc_run_core
| | kvmppc_vcpu_run_hv
| | kvmppc_vcpu_run
| | kvm_arch_vcpu_ioctl_run
| | kvm_vcpu_ioctl
| | do_vfs_ioctl
| | sys_ioctl
| | system_call
| | __ioctl
| | 0x7e714
| | 0x7e714
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/perf/core-book3s.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -112,7 +112,16 @@ static inline void power_pmu_bhrb_read(s
static bool regs_use_siar(struct pt_regs *regs)
{
- return !!regs->result;
+ /*
+ * When we take a performance monitor exception the regs are setup
+ * using perf_read_regs() which overloads some fields, in particular
+ * regs->result to tell us whether to use SIAR.
+ *
+ * However if the regs are from another exception, eg. a syscall, then
+ * they have not been setup using perf_read_regs() and so regs->result
+ * is something random.
+ */
+ return ((TRAP(regs) == 0xf00) && regs->result);
}
/*
next prev parent reply other threads:[~2015-07-08 7:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 7:31 [PATCH 3.10 00/14] 3.10.84-stable review Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 01/14] sparc: Use GFP_ATOMIC in ldc_alloc_exp_dring() as it can be called in softirq context Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 02/14] bridge: fix multicast router rlist endless loop Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 03/14] bridge: fix br_stp_set_bridge_priority race conditions Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 04/14] packet: read num_members once in packet_rcv_fanout() Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 05/14] packet: avoid out of bounds read in round robin fanout Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 06/14] sctp: Fix race between OOTB responce and route removal Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 07/14] crypto: talitos - avoid memleak in talitos_alg_alloc() Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 08/14] Revert "crypto: talitos - convert to use be16_add_cpu()" Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 09/14] arm: KVM: force execution of HCPTR access on VM exit Greg Kroah-Hartman
2015-07-08 7:31 ` Greg Kroah-Hartman [this message]
2015-07-08 7:31 ` [PATCH 3.10 11/14] x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 12/14] MIPS: Fix KVM guest fixmap address Greg Kroah-Hartman
2015-07-08 7:31 ` [PATCH 3.10 14/14] fs: Fix S_NOSEC handling Greg Kroah-Hartman
2015-07-08 14:06 ` [PATCH 3.10 00/14] 3.10.84-stable review Guenter Roeck
2015-07-08 14:42 ` Sudip Mukherjee
2015-07-08 16:33 ` Shuah Khan
2015-07-09 18:13 ` Kevin Hilman
2015-07-10 17:34 ` Greg Kroah-Hartman
2015-07-10 18:51 ` Kevin Hilman
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=20150708073102.764578543@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=anton@samba.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=stable@vger.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 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).