Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp3621642ybl; Mon, 12 Aug 2019 03:41:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqwUAKpovaLn0d2mz/BxFhtc1CEcAEY5PL7rBvAE++wUAhYMk4CKtAV8pCRpqbH1/R9mjIWS X-Received: by 2002:a63:5920:: with SMTP id n32mr28552052pgb.352.1565606476089; Mon, 12 Aug 2019 03:41:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565606476; cv=none; d=google.com; s=arc-20160816; b=Sm1jiyJzczRz5lm5JkdYypClQ5o3GGtELeLVLjJymv4+ScvpVouZ5P99rNYNbdbYcB BxXpMwlcBfYuWW31+LqMFYIG1TPzOFbA9PgFZT4zxP4b7XPkCFzcerGVMqAME71KWgXv 6rWI7BG2EoCEo/GmFxcCWWL7TBhOcZa/wIRtjy5BxsCHyQL7iymWLxH08GTIGYVp1fRy vx/9hTeTcVb79d6yl2XiNDmaafjoFMlwnU6UStJfaRj1U9oUmZNVEnQ0y0LrNKsw1j7l M8lVuD/8KfNygPyKL5Ol/gFCO/egFIIo/KOPgwMRrNR6YoZOa24KswDhJS7mYxqF0FBH co7Q== 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=aAmTw6Bu5u3cGZ9u4mrsYPSz1igbdj21t1tqvwbjPLk=; b=tJ2P9slpK1tqd2HeKVSDP4vDS8qoKF1I6Ed0AxKQe5MkUEbJenrCYRKGjMrCuYlaxp 9donx1CDp0cIqHXELJX1ibmsZIQCylx/m1bfgN778FR3ZdufJzfqbENK8sgIwStgVTtl tOkEKOfeoDV6Eov1rEfqP9iHpW0TW0qlGN3BbQYO8XKcuQcnNAiucSm67beqn/Y+ALPH lpjwjD76mLhqPAx+Ogacf9zju1nwmUUXnropWBes4WBq30Uehz667+hE44KPUtG/86lu W52m32doRzd5xB0e5HvFwqEkHOVUg3869rjlFuFuoENrF8EjS0hmwBU28bXKDR7eov4D fwAA== 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 q10si11248434pjq.46.2019.08.12.03.41.00; Mon, 12 Aug 2019 03:41:16 -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 S1728003AbfHLKjD (ORCPT + 99 others); Mon, 12 Aug 2019 06:39:03 -0400 Received: from foss.arm.com ([217.140.110.172]:47956 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727803AbfHLKjC (ORCPT ); Mon, 12 Aug 2019 06:39:02 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C9FC615AB; Mon, 12 Aug 2019 03:39:01 -0700 (PDT) Received: from dawn-kernel.cambridge.arm.com (unknown [10.1.197.116]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1EBDF3F706; Mon, 12 Aug 2019 03:39:01 -0700 (PDT) Subject: Re: [PATCH v2] coresight: Serialize enabling/disabling a link device. To: yabinc@google.com, mathieu.poirier@linaro.org, alexander.shishkin@linux.intel.com Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20190809214538.29677-1-yabinc@google.com> From: Suzuki K Poulose Message-ID: <056f411f-eef2-752e-0c02-2e5ed803cc62@arm.com> Date: Mon, 12 Aug 2019 11:38:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190809214538.29677-1-yabinc@google.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 Yabin, On 09/08/2019 22:45, Yabin Cui wrote: > When tracing etm data of multiple threads on multiple cpus through perf > interface, some link devices are shared between paths of different cpus. > It creates race conditions when different cpus wants to enable/disable > the same link device at the same time. > > Example 1: > Two cpus want to enable different ports of a coresight funnel, thus > calling the funnel enable operation at the same time. But the funnel > enable operation isn't reentrantable. > > Example 2: > For an enabled coresight dynamic replicator with refcnt=1, one cpu wants > to disable it, while another cpu wants to enable it. Ideally we still have > an enabled replicator with refcnt=1 at the end. But in reality the result > is uncertain. > > Since coresight devices claim themselves when enabled for self-hosted > usage, the race conditions above usually make the link devices not usable > after many cycles. > > To fix the race conditions, this patch adds a spinlock to serialize > enabling/disabling a link device. > > Signed-off-by: Yabin Cui > --- > > v1 -> v2: extend lock range to protect read of refcnt in > coresight_disable_link(). Thanks for this. Please find my comments below. > > --- > drivers/hwtracing/coresight/coresight.c | 12 +++++++++++- > include/linux/coresight.h | 3 +++ > 2 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight.c b/drivers/hwtracing/coresight/coresight.c > index 55db77f6410b..e526bdeaeb22 100644 > --- a/drivers/hwtracing/coresight/coresight.c > +++ b/drivers/hwtracing/coresight/coresight.c > @@ -256,6 +256,7 @@ static int coresight_enable_link(struct coresight_device *csdev, > int ret; > int link_subtype; > int refport, inport, outport; > + unsigned long flags; > > if (!parent || !child) > return -EINVAL; > @@ -274,15 +275,18 @@ static int coresight_enable_link(struct coresight_device *csdev, > if (refport < 0) > return refport; > > + spin_lock_irqsave(&csdev->spinlock, flags); > if (atomic_inc_return(&csdev->refcnt[refport]) == 1) { > if (link_ops(csdev)->enable) { > ret = link_ops(csdev)->enable(csdev, inport, outport); > if (ret) { > atomic_dec(&csdev->refcnt[refport]); > + spin_unlock_irqrestore(&csdev->spinlock, flags); > return ret; > } > } > } > + spin_unlock_irqrestore(&csdev->spinlock, flags); > > csdev->enable = true; Please could we move this inside the spin_lock () too ? > > @@ -296,6 +300,7 @@ static void coresight_disable_link(struct coresight_device *csdev, > int i, nr_conns; > int link_subtype; > int refport, inport, outport; > + unsigned long flags; > > if (!parent || !child) > return; > @@ -315,14 +320,18 @@ static void coresight_disable_link(struct coresight_device *csdev, > nr_conns = 1; > } > > + spin_lock_irqsave(&csdev->spinlock, flags); > if (atomic_dec_return(&csdev->refcnt[refport]) == 0) { > if (link_ops(csdev)->disable) > link_ops(csdev)->disable(csdev, inport, outport); > } > > for (i = 0; i < nr_conns; i++) > - if (atomic_read(&csdev->refcnt[i]) != 0) > + if (atomic_read(&csdev->refcnt[i]) != 0) { > + spin_unlock_irqrestore(&csdev->spinlock, flags); > return; > + } > + spin_unlock_irqrestore(&csdev->spinlock, flags); > > csdev->enable = false; > } And this too ? I understand this may not be used right now, but we can avoid any surprises when we do so. With the above fixed, : Reviewed-by: Suzuki K Poulose