linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tip-bot for Alexander Shishkin <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: tglx@linutronix.de, hpa@zytor.com, peterz@infradead.org,
	linux-kernel@vger.kernel.org, vincent.weaver@maine.edu,
	eranian@google.com, torvalds@linux-foundation.org,
	acme@redhat.com, mingo@kernel.org, jolsa@redhat.com,
	alexander.shishkin@linux.intel.com, acme@infradead.org
Subject: [tip:perf/core] perf/x86/intel/bts: Fix BTS PMI detection
Date: Sat, 10 Sep 2016 05:39:36 -0700	[thread overview]
Message-ID: <tip-4d4c474124649198d9b0a065c06f9362cf18e14e@git.kernel.org> (raw)
In-Reply-To: <20160906132353.19887-5-alexander.shishkin@linux.intel.com>

Commit-ID:  4d4c474124649198d9b0a065c06f9362cf18e14e
Gitweb:     http://git.kernel.org/tip/4d4c474124649198d9b0a065c06f9362cf18e14e
Author:     Alexander Shishkin <alexander.shishkin@linux.intel.com>
AuthorDate: Tue, 6 Sep 2016 16:23:52 +0300
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 10 Sep 2016 11:15:38 +0200

perf/x86/intel/bts: Fix BTS PMI detection

Since BTS doesn't have a dedicated PMI status bit, the driver needs to
take extra care to check for the condition that triggers it to avoid
spurious NMI warnings.

Regardless of the local BTS context state, the only way of knowing that
the NMI is ours is to compare the write pointer against the interrupt
threshold.

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160906132353.19887-5-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/events/intel/bts.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 61e1d71..9233edf 100644
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -446,26 +446,37 @@ bts_buffer_reset(struct bts_buffer *buf, struct perf_output_handle *handle)
 
 int intel_bts_interrupt(void)
 {
+	struct debug_store *ds = this_cpu_ptr(&cpu_hw_events)->ds;
 	struct bts_ctx *bts = this_cpu_ptr(&bts_ctx);
 	struct perf_event *event = bts->handle.event;
 	struct bts_buffer *buf;
 	s64 old_head;
-	int err = -ENOSPC;
+	int err = -ENOSPC, handled = 0;
+
+	/*
+	 * The only surefire way of knowing if this NMI is ours is by checking
+	 * the write ptr against the PMI threshold.
+	 */
+	if (ds->bts_index >= ds->bts_interrupt_threshold)
+		handled = 1;
 
 	/*
 	 * this is wrapped in intel_bts_enable_local/intel_bts_disable_local,
 	 * so we can only be INACTIVE or STOPPED
 	 */
 	if (READ_ONCE(bts->state) == BTS_STATE_STOPPED)
-		return 0;
+		return handled;
 
 	buf = perf_get_aux(&bts->handle);
+	if (!buf)
+		return handled;
+
 	/*
 	 * Skip snapshot counters: they don't use the interrupt, but
 	 * there's no other way of telling, because the pointer will
 	 * keep moving
 	 */
-	if (!buf || buf->snapshot)
+	if (buf->snapshot)
 		return 0;
 
 	old_head = local_read(&buf->head);
@@ -473,7 +484,7 @@ int intel_bts_interrupt(void)
 
 	/* no new data */
 	if (old_head == local_read(&buf->head))
-		return 0;
+		return handled;
 
 	perf_aux_output_end(&bts->handle, local_xchg(&buf->data_size, 0),
 			    !!local_xchg(&buf->lost, 0));

  reply	other threads:[~2016-09-10 12:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06 13:23 [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent Alexander Shishkin
2016-09-06 13:23 ` [PATCH v2 1/5] perf: Fix a race between mmap_close and set_output of AUX events Alexander Shishkin
2016-09-10 12:38   ` [tip:perf/core] perf/core: Fix a race between mmap_close() and set_output() " tip-bot for Alexander Shishkin
2016-09-06 13:23 ` [PATCH v2 2/5] perf: Fix aux_mmap_count vs aux_refcount order Alexander Shishkin
2016-09-10 12:38   ` [tip:perf/core] perf/core: " tip-bot for Alexander Shishkin
2016-09-06 13:23 ` [PATCH v2 3/5] perf/x86/intel/bts: Fix confused ordering of PMU callbacks Alexander Shishkin
2016-09-10 12:39   ` [tip:perf/core] " tip-bot for Alexander Shishkin
2016-09-06 13:23 ` [PATCH v2 4/5] perf/x86/intel/bts: Fix BTS PMI detection Alexander Shishkin
2016-09-10 12:39   ` tip-bot for Alexander Shishkin [this message]
2016-09-20 13:12   ` [PATCH] perf/x86/intel/bts: don't dereference ds unconditionally Sebastian Andrzej Siewior
2016-09-20 13:44     ` Alexander Shishkin
2016-09-20 13:54       ` Alexander Shishkin
2016-09-20 14:13     ` [tip:perf/urgent] perf/x86/intel/bts: Make sure debug store is valid tip-bot for Sebastian Andrzej Siewior
2016-09-06 13:23 ` [PATCH v2 5/5] perf/x86/intel/bts: Kill a silly warning Alexander Shishkin
2016-09-10 12:40   ` [tip:perf/core] " tip-bot for Alexander Shishkin
2016-09-06 17:19 ` [PATCH v2 0/5] perf, bts: Fallout from the fuzzer for perf/urgent Ingo Molnar
2016-09-07  0:13   ` Vince Weaver
2016-09-07 15:20   ` Alexander Shishkin
2016-09-07 15:36     ` Vince Weaver
2016-09-07 16:38       ` Peter Zijlstra
2016-09-07 18:33       ` Alexander Shishkin
2016-09-08  3:36         ` Vince Weaver
2016-09-08  8:51           ` Alexander Shishkin
2016-09-08 12:54             ` Vince Weaver
2016-09-08  6:21     ` Ingo Molnar
2016-09-08  6:23       ` Ingo Molnar
2016-09-08  8:43       ` Alexander Shishkin

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=tip-4d4c474124649198d9b0a065c06f9362cf18e14e@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=acme@infradead.org \
    --cc=acme@redhat.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=eranian@google.com \
    --cc=hpa@zytor.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.weaver@maine.edu \
    /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).