From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932607AbcBYIGt (ORCPT ); Thu, 25 Feb 2016 03:06:49 -0500 Received: from torg.zytor.com ([198.137.202.12]:58862 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932337AbcBYIGr (ORCPT ); Thu, 25 Feb 2016 03:06:47 -0500 Date: Thu, 25 Feb 2016 00:06:10 -0800 From: tip-bot for Peter Zijlstra Message-ID: Cc: acme@redhat.com, mingo@kernel.org, alexander.shishkin@linux.intel.com, jolsa@redhat.com, torvalds@linux-foundation.org, tglx@linutronix.de, peterz@infradead.org, linux-kernel@vger.kernel.org, hpa@zytor.com Reply-To: hpa@zytor.com, tglx@linutronix.de, linux-kernel@vger.kernel.org, peterz@infradead.org, torvalds@linux-foundation.org, mingo@kernel.org, acme@redhat.com, jolsa@redhat.com, alexander.shishkin@linux.intel.com In-Reply-To: <20160224174948.040469884@infradead.org> References: <20160224174948.040469884@infradead.org> To: linux-tip-commits@vger.kernel.org Subject: [tip:perf/urgent] perf: Cure event->pending_disable race Git-Commit-ID: 28a967c3a2f99fa3b5f762f25cb2a319d933571b X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 28a967c3a2f99fa3b5f762f25cb2a319d933571b Gitweb: http://git.kernel.org/tip/28a967c3a2f99fa3b5f762f25cb2a319d933571b Author: Peter Zijlstra AuthorDate: Wed, 24 Feb 2016 18:45:46 +0100 Committer: Ingo Molnar CommitDate: Thu, 25 Feb 2016 08:42:34 +0100 perf: Cure event->pending_disable race Because event_sched_out() checks event->pending_disable _before_ actually disabling the event, it can happen that the event fires after it checks but before it gets disabled. This would leave event->pending_disable set and the queued irq_work will try and process it. However, if the event trigger was during schedule(), the event might have been de-scheduled by the time the irq_work runs, and perf_event_disable_local() will fail. Fix this by checking event->pending_disable _after_ we call event->pmu->del(). This depends on the latter being a compiler barrier, such that the compiler does not lift the load and re-creates the problem. Tested-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: dvyukov@google.com Cc: eranian@google.com Cc: oleg@redhat.com Cc: panand@redhat.com Cc: sasha.levin@oracle.com Cc: vince@deater.net Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org Signed-off-by: Ingo Molnar --- kernel/events/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index ea064ca..de14b67 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -1696,14 +1696,14 @@ event_sched_out(struct perf_event *event, perf_pmu_disable(event->pmu); + event->tstamp_stopped = tstamp; + event->pmu->del(event, 0); + event->oncpu = -1; event->state = PERF_EVENT_STATE_INACTIVE; if (event->pending_disable) { event->pending_disable = 0; event->state = PERF_EVENT_STATE_OFF; } - event->tstamp_stopped = tstamp; - event->pmu->del(event, 0); - event->oncpu = -1; if (!is_software_event(event)) cpuctx->active_oncpu--;