Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1073826yba; Thu, 4 Apr 2019 03:49:02 -0700 (PDT) X-Google-Smtp-Source: APXvYqzHEftFp8fTvpS+GzZ3XDNifLTtip0buM4D8H/VwVp9LaY82mA0gBMQ1wkaNM4Hbymq5ac3 X-Received: by 2002:aa7:90ca:: with SMTP id k10mr5175732pfk.144.1554374942404; Thu, 04 Apr 2019 03:49:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554374942; cv=none; d=google.com; s=arc-20160816; b=UNHCg1/AyNhi6cJ/SZgVfpeT5OSnExxIkag0kBJOeimebjgsUyYl3Ghn8rkNXOe/hz 1NYEN3nxHYbeHS/nh++drNbWorzblOoq34Dt/UePjRPXZxD2V2MHGPt+HKd9d02685UD M7F657c9FO3rX7A2b7OBAMMKi7L2h9rOu+9tnjQDglPDkTwpiWneYAT3Tt76mdTMmrQO GBt3IMNG8g/57J8tpiKfu0pK1d+o9/k20mWZxd3+jKY9bzfiNmSbV8IDS709u0TCCrGM obLEMl/ssW/JmUCoA9doTRgjfGf5ZVz4m1ilsKHYw9StAJVUgVGsaCJIvskjjJ1KUAiZ +5kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Q5lnewhECo/BBLdHhZXRA02j+rKDriJo4+/kqnGr+9k=; b=SW0KbBIlLk+iwK39/iEbBlgEIF68NwNRm7n8D+fsPD+3Cn4EYVJT6zmda3rAilXE1T iVA8GyAT0fBCiXi6wADq9mVe/5hGCWvXrYCAAtQyBp3riMmBW66BFvooDP7IAPDpLYML GANEF9/Byz/Oldy5E5YmUSWwG/lQvQzBmE6bGUlzFHr4AAhEnViMYndjGaHBCqWqJxrq yiPFBk+TOJ9Py1sSbMZoroUA1Sd7e4AOoYBb9fLb98joaC6ljOenjFgY9a1Oa36opDqk drTHjo0CPHb6UTFrG2RpIETDVbSszZnJc20rtxaPHiJr5JBWAq0ObuWrTygo/2TyY387 vMjQ== 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 z186si14574998pgd.155.2019.04.04.03.48.47; Thu, 04 Apr 2019 03:49:02 -0700 (PDT) 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 S1729289AbfDDKqy (ORCPT + 99 others); Thu, 4 Apr 2019 06:46:54 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:57880 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726694AbfDDKqy (ORCPT ); Thu, 4 Apr 2019 06:46:54 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E660CA78; Thu, 4 Apr 2019 03:46:53 -0700 (PDT) Received: from [10.1.196.93] (en101.cambridge.arm.com [10.1.196.93]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4734E3F557; Thu, 4 Apr 2019 03:46:52 -0700 (PDT) Subject: Re: [PATCH v2 2/2] perf/arm-ccn: Remove broken race mitigation To: robin.murphy@arm.com, will.deacon@arm.com Cc: mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, bigeasy@linutronix.de, peterz@infradead.org, clabbe.montjoie@gmail.com, Meng.Li@windriver.com References: <49087b08f2685bed112dfc90b97ae59b8de8f6cf.1554310292.git.robin.murphy@arm.com> From: Suzuki K Poulose Message-ID: <2cbf5e2c-8a79-f2da-680f-ce20792ae2af@arm.com> Date: Thu, 4 Apr 2019 11:46:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <49087b08f2685bed112dfc90b97ae59b8de8f6cf.1554310292.git.robin.murphy@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robin, On 03/04/2019 18:10, Robin Murphy wrote: > Like arm-cci, arm-ccn has the same issue of disabling preemption around > operations which can take mutexes. Again, remove the definite bug by > simply not trying to fight the theoretical races. And since we are > touching the hotplug handling code, take the opportunity to streamline > it, as there's really no need to store a full-sized cpumask to keep > track of a single CPU ID. > > Signed-off-by: Robin Murphy > --- > drivers/perf/arm-ccn.c | 23 +++++++++++------------ > 1 file changed, 11 insertions(+), 12 deletions(-) > > diff --git a/drivers/perf/arm-ccn.c b/drivers/perf/arm-ccn.c > index 2ae76026e947..a0214308b0cd 100644 > --- a/drivers/perf/arm-ccn.c > +++ b/drivers/perf/arm-ccn.c > /* Pick one CPU which we will use to collect data from CCN... */ > - cpumask_set_cpu(get_cpu(), &ccn->dt.cpu); > + ccn->dt.cpu = raw_smp_processor_id(); > > /* Also make sure that the overflow interrupt is handled by this CPU */ > if (ccn->irq) { > - err = irq_set_affinity_hint(ccn->irq, &ccn->dt.cpu); > + err = irq_set_affinity_hint(ccn->irq, cpumask_of(ccn->dt.cpu)); > if (err) { > dev_err(ccn->dev, "Failed to set interrupt affinity!\n"); > goto error_set_affinity; > } > } > > + cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCN_ONLINE, > + &ccn->dt.node); > + > err = perf_pmu_register(&ccn->dt.pmu, name, -1); > if (err) > goto error_pmu_register; Should we not remove the above instance, in case we fail to register the PMU ? Similarly for the CCI driver, we may have to reset the g_cci_pmu if we fail. Cheers Suzuki > > - cpuhp_state_add_instance_nocalls(CPUHP_AP_PERF_ARM_CCN_ONLINE, > - &ccn->dt.node); > - put_cpu(); > return 0; > > error_pmu_register: > error_set_affinity: > - put_cpu(); > error_choose_name: > ida_simple_remove(&arm_ccn_pmu_ida, ccn->dt.id); > for (i = 0; i < ccn->num_xps; i++) >