From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 28A29C3600C for ; Mon, 31 Mar 2025 15:13:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=LNPJ7XIeNZX7ncLNDHeMMH3zEghD+FfavKDPvEMHMAg=; b=Y5enF4K3bfogklEAmvm97aZaCw +aUhSM4cXbNX88vb36Xi6RfQuTedABs9pZHecFZbJ8LMRrP2W0rqRfTMRBi6VPQWYcntxUPS1hqby OfuRzPMp1YKZQnS3blxEZckOhnkBLk1yHt9NevWx5EoiozxYRFxcBtQApeGe5SjdnwABbgWmTv4Rt PbQ6u0AzkxRCjxh2Lrep1IHQEa053ANaSt6xGJUWOOW4V+ipjKHyRBmNtsoSNZpaX5qgmdovVtVmt wP9pIqR4noWWbkS2Nom/87bxciXTcq2utpTuTXPdlQ7DBY/SGZmVun3DBvVapzVGA6VU8qgKOe83y pgg7Hd1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.1 #2 (Red Hat Linux)) id 1tzGp1-00000000j25-1Knc; Mon, 31 Mar 2025 15:13:07 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.1 #2 (Red Hat Linux)) id 1tzGGe-00000000aVb-3fo4 for linux-arm-kernel@lists.infradead.org; Mon, 31 Mar 2025 14:37:38 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 20EBB44CB3; Mon, 31 Mar 2025 14:37:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49AC9C4CEE3; Mon, 31 Mar 2025 14:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743431856; bh=xi/tBwIFHKyfGEr00a3gAhnzwGrPSduGYFVcYB2eJlU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dvRW15QFAl6IxdPQ7f2TMlP6lzSXxoIvwTApFjKLRlfSAEQGhtUQZ8A6n9hrTWqQQ eOJLmUZ4QFCtihswXDSxWbky6qRpRd66je8pn6mQQ1BHruMPh9jQ/jQ/pMCAK6Yabr sg74mSRhLC+myTEubYL3E5wrC8cSvZLtw98jZeXvaQ6kJ1kK83MfMmLOGnDsiqNEnK 1hCd3k6XnOJkZ3agC8gef7lbmkmuL2SxVF9ftN7Y2zQzTrHsbYUGNFpmZdue41Cd3D XnWIUwuYOPcw4RCPvISiS1NTE4hDPZtGqB36/Vvw/e8IbMPno/kBjfUAaj0q/mAAnP zYDDTqaHSxxWQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mark Rutland , Rob Herring , Anshuman Khandual , James Clark , Will Deacon , Sasha Levin , linux-arm-kernel@lists.infradead.org, linux-perf-users@vger.kernel.org Subject: [PATCH AUTOSEL 5.4 3/5] perf: arm_pmu: Don't disable counter in armpmu_add() Date: Mon, 31 Mar 2025 10:37:24 -0400 Message-Id: <20250331143728.1686696-3-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250331143728.1686696-1-sashal@kernel.org> References: <20250331143728.1686696-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 5.4.291 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250331_073736_954087_4B1E1C09 X-CRM114-Status: GOOD ( 18.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Mark Rutland [ Upstream commit dcca27bc1eccb9abc2552aab950b18a9742fb8e7 ] Currently armpmu_add() tries to handle a newly-allocated counter having a stale associated event, but this should not be possible, and if this were to happen the current mitigation is insufficient and potentially expensive. It would be better to warn if we encounter the impossible case. Calls to pmu::add() and pmu::del() are serialized by the core perf code, and armpmu_del() clears the relevant slot in pmu_hw_events::events[] before clearing the bit in pmu_hw_events::used_mask such that the counter can be reallocated. Thus when armpmu_add() allocates a counter index from pmu_hw_events::used_mask, it should not be possible to observe a stale even in pmu_hw_events::events[] unless either pmu_hw_events::used_mask or pmu_hw_events::events[] have been corrupted. If this were to happen, we'd end up with two events with the same event->hw.idx, which would clash with each other during reprogramming, deletion, etc, and produce bogus results. Add a WARN_ON_ONCE() for this case so that we can detect if this ever occurs in practice. That possiblity aside, there's no need to call arm_pmu::disable(event) for the new event. The PMU reset code initialises the counter in a disabled state, and armpmu_del() will disable the counter before it can be reused. Remove the redundant disable. Signed-off-by: Mark Rutland Signed-off-by: Rob Herring (Arm) Reviewed-by: Anshuman Khandual Tested-by: James Clark Link: https://lore.kernel.org/r/20250218-arm-brbe-v19-v20-2-4e9922fc2e8e@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin --- drivers/perf/arm_pmu.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index b377872a8f9d6..558ee5401ea89 100644 --- a/drivers/perf/arm_pmu.c +++ b/drivers/perf/arm_pmu.c @@ -262,12 +262,10 @@ armpmu_add(struct perf_event *event, int flags) if (idx < 0) return idx; - /* - * If there is an event in the counter we are going to use then make - * sure it is disabled. - */ + /* The newly-allocated counter should be empty */ + WARN_ON_ONCE(hw_events->events[idx]); + event->hw.idx = idx; - armpmu->disable(event); hw_events->events[idx] = event; hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE; -- 2.39.5