Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3324516imu; Sun, 11 Nov 2018 12:23:42 -0800 (PST) X-Google-Smtp-Source: AJdET5eViS/Lj0oa1XFeVGTfDibToHnNOF7SsYAEptl4wjDEZ647gjhIH7PUIT0FSSUqKmNp8HA6 X-Received: by 2002:a17:902:74ca:: with SMTP id f10mr1305504plt.273.1541967822045; Sun, 11 Nov 2018 12:23:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541967822; cv=none; d=google.com; s=arc-20160816; b=nxCJ+IQ2xFeLCLEl2Fv5FIk1Wr1QoLvb2WCd64PPljD3cz6NKq2JurQWGnIIqZT04T SwAGVpDrd+2VkCsdANwBnudR9fg7RmhTJaGwp7Bn6Zied6O/GPjTi2hNXxDX2iIUAfEp pEDPSwRLzz9bsULv7Auci1AvlGmQ+fDJIjmGfpWEWWGYom8sqK2o8NR+inbgx4Lte+NU ez90DANLkF4QFdJfW26VdPEuMqo6vTlYdYe4Xm9QKYFywTCw1eFje0v6DViw+hmGZ7Rg sDSYjfeVVlcwX3vtp/zf0Odg/FzzLUaVxXe7fE05kBXhvoEVeMBM16zNJHyLr70jYw+/ Fvlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=NRk1YE/hX7/ejC8wMIdAimPQAB5iNtsXiB5NW617kvY=; b=tnxlC2KkV4RHRXwNuw3GISgFGd1Tkhr4CDgw0bgMy2IgKXBlCM2bFeiWfmLH4cM8H+ xHExkYQRUpFz3IkyFl7Rq0iKK52Umo6Hz/++8xwYYUR0QErOAA2iAGdNWw3n01kokf1m PnjBQ2jI0cUdNmZfv1b2KYiTa/RAm6m/HiegpD9bu/VGgQ2Sb2YbLs4SFiCrU2hAz0oW 0kyIO+s2jlqFH5EHdXFMbHQa5clhNqapeWb6Q4gS/xmFpA0JxLohPtk6AYW0Sgkhrhgp u3c8GU7c8yKWwtwS/4mw0ysOl03+DinCmEgTXdB4x+41jO4qQUndZN05bioXyjlqEsZi dXcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b12-v6si15029505plr.175.2018.11.11.12.23.27; Sun, 11 Nov 2018 12:23:42 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729725AbeKLFyo (ORCPT + 99 others); Mon, 12 Nov 2018 00:54:44 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:51750 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731170AbeKLFyY (ORCPT ); Mon, 12 Nov 2018 00:54:24 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvt6-0000oG-Nb; Sun, 11 Nov 2018 19:59:16 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsQ-0001Th-By; Sun, 11 Nov 2018 19:58:34 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Ingo Molnar" , "Song Liu" , "Thomas Gleixner" , "Alexander Shishkin" , "" , "Jiri Olsa" , "Arnaldo Carvalho de Melo" , "Linus Torvalds" , "Peter Zijlstra (Intel)" , "Vince Weaver" , "Stephane Eranian" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 087/366] perf/core: Fix group scheduling with mixed hw and sw events In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Song Liu commit a1150c202207cc8501bebc45b63c264f91959260 upstream. When hw and sw events are mixed in the same group, they are all attached to the hw perf_event_context. This sometimes requires moving group of perf_event to a different context. We found a bug in how the kernel handles this, for example if we do: perf stat -e '{faults,ref-cycles,faults}' -I 1000 1.005591180 1,297 faults 1.005591180 457,476,576 ref-cycles 1.005591180 faults First, sw event "faults" is attached to the sw context, and becomes the group leader. Then, hw event "ref-cycles" is attached, so both events are moved to the hw context. Last, another sw "faults" tries to attach, but it fails because of mismatch between the new target ctx (from sw pmu) and the group_leader's ctx (hw context, same as ref-cycles). The broken condition is: group_leader is sw event; group_leader is on hw context; add a sw event to the group. Fix this scenario by checking group_leader's context (instead of just event type). If group_leader is on hw context, use the ->pmu of this context to look up context for the new event. Signed-off-by: Song Liu Signed-off-by: Peter Zijlstra (Intel) Cc: Cc: Alexander Shishkin Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Fixes: b04243ef7006 ("perf: Complete software pmu grouping") Link: http://lkml.kernel.org/r/20180503194716.162815-1-songliubraving@fb.com Signed-off-by: Ingo Molnar [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- include/linux/perf_event.h | 8 ++++++++ kernel/events/core.c | 21 +++++++++++---------- 2 files changed, 19 insertions(+), 10 deletions(-) --- a/include/linux/perf_event.h +++ b/include/linux/perf_event.h @@ -640,6 +640,14 @@ static inline int is_software_event(stru return event->pmu->task_ctx_nr == perf_sw_context; } +/* + * Return 1 for event in sw context, 0 for event in hw context + */ +static inline int in_software_context(struct perf_event *event) +{ + return event->ctx->pmu->task_ctx_nr == perf_sw_context; +} + extern struct static_key perf_swevent_enabled[PERF_COUNT_SW_MAX]; extern void ___perf_sw_event(u32, u64, struct pt_regs *, u64); --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -7502,19 +7502,20 @@ SYSCALL_DEFINE5(perf_event_open, */ pmu = event->pmu; - if (group_leader && - (is_software_event(event) != is_software_event(group_leader))) { - if (is_software_event(event)) { + if (group_leader) { + if (is_software_event(event) && + !in_software_context(group_leader)) { /* - * If event and group_leader are not both a software - * event, and event is, then group leader is not. + * If the event is a sw event, but the group_leader + * is on hw context. * - * Allow the addition of software events to !software - * groups, this is safe because software events never - * fail to schedule. + * Allow the addition of software events to hw + * groups, this is safe because software events + * never fail to schedule. */ - pmu = group_leader->pmu; - } else if (is_software_event(group_leader) && + pmu = group_leader->ctx->pmu; + } else if (!is_software_event(event) && + is_software_event(group_leader) && (group_leader->group_flags & PERF_GROUP_SOFTWARE)) { /* * In case the group is a pure software group, and we