From: Thomas Gleixner <tglx@linutronix.de>
To: Emmanuel Berthier <emmanuel.berthier@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, robert.jarzmik@intel.com,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>
Subject: Re: [PATCH v2] [LBR] Dump LBRs on Exception
Date: Thu, 27 Nov 2014 22:22:50 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.11.1411271609510.3961@nanos> (raw)
In-Reply-To: <1417099205-13309-1-git-send-email-emmanuel.berthier@intel.com>
On Thu, 27 Nov 2014, Emmanuel Berthier wrote:
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> index 45fa730..0a69365 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
> @@ -4,7 +4,7 @@
> #include <asm/perf_event.h>
> #include <asm/msr.h>
> #include <asm/insn.h>
> -
This newline is intentional to seperate asm includes from the local
one.
> static void __intel_pmu_lbr_enable(void)
> {
> u64 debugctl;
> struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
>
> + lbr_set_used_by_perf(true);
This cannot work.
CPU0 CPU1
__intel_pmu_lbr_enable()
lbr_set_used_by_perf(true);
__intel_pmu_lbr_disable()
lbr_set_used_by_perf(false);
This is a per cpu property.
And there is more to that. Let's look at a single CPU.
lbr for oops is enabled
context switch()
__intel_pmu_lbr_enable() -> LBR used by perf, oops dumper disabled
context switch()
__intel_pmu_lbr_disable() -> LBR not longer used by perf, oops
dumper enabled
So after that context switch we crash in the kernel and LBR is empty
because we did disable it at the context switch.
So you need per cpu state, which handles the LBR dumper state:
#define LBR_OOPS_DISABLED 0x01
#define LBR_PERF_USAGE 0x02
DEFINE_PER_CPU(unsigned long, lbr_dump_state) = LBR_OOPS_DISABLED;
lbr_perf_enable()
this_cpu_add(lbr_dump_state, LBR_PERF_USAGE);
lbr_perf_disable()
if (!this_cpu_sub_return(lbr_dump_state, LBR_PERF_USAGE))
enable_lbr_oops();
Now of course you need to handle this in the exception path per cpu as
well.
> /*
> * Exception entry points.
> */
> @@ -1063,6 +1103,8 @@ ENTRY(\sym)
> subq $ORIG_RAX-R15, %rsp
> CFI_ADJUST_CFA_OFFSET ORIG_RAX-R15
>
> + STOP_LBR
We really cannot do this unconditionally for every exception. This
wants to be conditional, i.e.
.if \stop_lbr
cond_stop_lbr
.endif
So we can select which exceptions actually get that treatment.
do_page_fault is probably the only one which is interesting
here.
Now looking at your macro maze, I really wonder whether we can do it a
little bit less convoluted. We need to push/pop registers. error_entry
saves the registers already and has a (admitedly convoluted)
kernel/user space check. But we might be able to do something sane
there. Cc'ing Andy as he is the master of that universe.
Thanks,
tglx
next prev parent reply other threads:[~2014-11-27 21:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-21 17:03 [PATCH] [LBR] Dump LBRs on Oops Emmanuel Berthier
2014-11-22 0:50 ` Thomas Gleixner
2014-11-26 10:56 ` Berthier, Emmanuel
2014-11-26 13:08 ` Thomas Gleixner
2014-11-26 14:17 ` Berthier, Emmanuel
2014-11-26 14:46 ` Thomas Gleixner
2014-11-26 15:43 ` Berthier, Emmanuel
2014-11-27 14:40 ` [PATCH v2] [LBR] Dump LBRs on Exception Emmanuel Berthier
2014-11-27 21:22 ` Thomas Gleixner [this message]
2014-11-27 21:56 ` Andy Lutomirski
2014-11-28 8:44 ` Berthier, Emmanuel
2014-11-28 15:15 ` Andy Lutomirski
2014-12-02 19:09 ` Berthier, Emmanuel
2014-12-02 19:33 ` Andy Lutomirski
2014-12-02 19:56 ` Thomas Gleixner
2014-12-02 20:12 ` Andy Lutomirski
2014-12-03 18:25 ` Berthier, Emmanuel
2014-12-03 19:29 ` Andy Lutomirski
2014-12-04 16:01 ` Berthier, Emmanuel
2014-12-04 18:09 ` Andy Lutomirski
2014-12-05 13:14 ` Berthier, Emmanuel
2014-12-06 10:31 ` Robert Jarzmik
[not found] ` <CALCETrXhfzd9Fkikvm5qj0LWgWtDzgdpY_0EC3ChwyyGZksTMw@mail.gmail.com>
2014-12-07 18:40 ` Robert Jarzmik
2014-12-07 19:10 ` Andy Lutomirski
2014-12-12 17:30 ` Berthier, Emmanuel
2014-12-12 17:54 ` Andy Lutomirski
2014-11-28 10:28 ` Berthier, Emmanuel
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=alpine.DEB.2.11.1411271609510.3961@nanos \
--to=tglx@linutronix.de \
--cc=emmanuel.berthier@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=robert.jarzmik@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®