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 1BA09C52D7D for ; Fri, 16 Aug 2024 13:28:20 +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: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7WCQM6v4NTwhI05qdS59VV07dC5nARwtW2tumhNxSAs=; b=Lu43nq3TEXF14wJ604lK+hIt/R g7xxnR4owIcLymMqWDR9axlvFN+pzGL6qeU6pQvPFq7nwVMpKw3mJSEiIK6wQQER3ayR/RaKhhmc8 VdisMBwhEkrMCjRaPylwpwz5TXzboLleOHdCkleSwkoLzrmllKJB4qPsh9QKRCrh8DfdSP4iEv68U Cz3GgCSNNr+Mm4YBCqF0Kwv9zYFVJpqFRVN5S78n1nnrTJocV6jpUMfU2oE1XcYIrYsk+qE6O8kRK Jx3T+DZryzZ8+o+jgEAopBs2knUQ1yo/oPjXHO7BFCGA6NbCzBDlshHE6pPh5d4USXo3MnI1brDeU SLmif4WA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sewzt-0000000D2iL-2EOV; Fri, 16 Aug 2024 13:28:05 +0000 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sewzE-0000000D2Z7-1RQQ for linux-arm-kernel@lists.infradead.org; Fri, 16 Aug 2024 13:27:26 +0000 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-42817bee9e8so13686035e9.3 for ; Fri, 16 Aug 2024 06:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1723814841; x=1724419641; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=7WCQM6v4NTwhI05qdS59VV07dC5nARwtW2tumhNxSAs=; b=OQXbZCQggEDlbiR4rQOGSYt4gtBoaayzbVbwv9mXwuOgDbmRXB4Cc9cr3qdYPr/MGV qu/xjbgUAXUH6ooEi4Ko4SCFbEggPjcncQiMxpSQKcINxHK2Pn2wUIK+xb23/O06NozX +zHjw4jMGjqJ7gY018JAekIPzipCUTZ+SO0CO+5GDQ8ETS4s6/fy4QeoAdzMJD4sWWxq 2c0BzN+L9I9XKAlkcBIRWe4Honjx1pv4thsFrEjtqwPXNL7EpK/HeucY1ess/VZlOHmM EuHtr+ummlqlwYQLEuRvY0qc+iGoXi/7y3vSUBy6uyC66p6bXocGBCtS7MZockfblCgX +UCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723814841; x=1724419641; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7WCQM6v4NTwhI05qdS59VV07dC5nARwtW2tumhNxSAs=; b=pedQnUKPjrLXlaWeKmsq0pd1Rs5fYzxcIHZID8lJSsfZlWb8o/uvplKoTgcrHYNWNV 4cFztqszzSdBNF/9X9Ot2JzJ9M4ShSsJdKOyMTyJBm3V6O78hLK/vbAkyKrvXW+atBE8 yZnOAnTAdhYJr+xtjZwI1XCSQq/4Wdl2QWxRaWw/pPYZqOpvQzrfQtC51Gdpp6aR46Zi 0WyL3bWLtM9EZ2s+gBPoJev7M1YuvyNK6o5TaCPjA/jz5crji7D2MN+xDPMqNyWzeIpE sKwQ5nqhBXTvjwBRFMDEvV+96EebhkyppZMtaPFwGL3Dn547j/iDi4wDmWf8s4c4bLT6 /J3w== X-Gm-Message-State: AOJu0YzaF46gkMLBDMEUaKINReKpY8Xx8OU9tYTzzNcgoROzT6X5jEB5 Zt7XdNbQNNv1csvrx/UldDuIlwa55leK0uYZaXKOhL2WN2vOVU+8sdcPyMaKMJM= X-Google-Smtp-Source: AGHT+IHbFkHu9392EA0i6PYQpeLlqoUxj+nwG7GXFX79pIwS5rABIJuq9XtLqO3ZGS6JxW3l8tgH3A== X-Received: by 2002:a05:600c:4ecb:b0:426:6379:3b4f with SMTP id 5b1f17b1804b1-429ed7dba98mr20081015e9.31.1723814840869; Fri, 16 Aug 2024 06:27:20 -0700 (PDT) Received: from [192.168.1.3] ([89.47.253.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429ed6585d1sm22808075e9.22.2024.08.16.06.27.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Aug 2024 06:27:20 -0700 (PDT) Message-ID: <177108bc-2bdd-4914-97cc-ee09dfef75c3@linaro.org> Date: Fri, 16 Aug 2024 14:27:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] drivers/perf: arm_spe: Use perf_allow_kernel() for permissions To: Will Deacon Cc: linux-arm-kernel@lists.infradead.org, peterz@infradead.org, Al Grant , Mark Rutland , Ingo Molnar , Arnaldo Carvalho de Melo , Namhyung Kim , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org References: <20240807155153.2714025-1-james.clark@linaro.org> <20240816124459.GA24323@willie-the-truck> Content-Language: en-US From: James Clark In-Reply-To: <20240816124459.GA24323@willie-the-truck> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240816_062724_423389_91505809 X-CRM114-Status: GOOD ( 30.64 ) 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 On 16/08/2024 1:45 pm, Will Deacon wrote: > On Wed, Aug 07, 2024 at 04:51:53PM +0100, James Clark wrote: >> For other PMUs, PERF_SAMPLE_PHYS_ADDR requires perf_allow_kernel() >> rather than just perfmon_capable(). Because PMSCR_EL1_PA is another form >> of physical address, make it consistent and use perf_allow_kernel() for >> SPE as well. PMSCR_EL1_PCT and PMSCR_EL1_CX also get the same change. >> >> This improves consistency and indirectly fixes the following error >> message which is misleading because perf_event_paranoid is not taken >> into account by perfmon_capable(): >> >> $ perf record -e arm_spe/pa_enable/ >> >> Error: >> Access to performance monitoring and observability operations is >> limited. Consider adjusting /proc/sys/kernel/perf_event_paranoid >> setting ... >> >> Suggested-by: Al Grant >> Signed-off-by: James Clark >> --- >> Changes since v1: >> >> * Export perf_allow_kernel() instead of sysctl_perf_event_paranoid >> >> drivers/perf/arm_spe_pmu.c | 9 ++++----- >> include/linux/perf_event.h | 8 +------- >> kernel/events/core.c | 9 +++++++++ >> 3 files changed, 14 insertions(+), 12 deletions(-) >> >> diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c >> index 9100d82bfabc..3569050f9cf3 100644 >> --- a/drivers/perf/arm_spe_pmu.c >> +++ b/drivers/perf/arm_spe_pmu.c >> @@ -41,7 +41,7 @@ >> >> /* >> * Cache if the event is allowed to trace Context information. >> - * This allows us to perform the check, i.e, perfmon_capable(), >> + * This allows us to perform the check, i.e, perf_allow_kernel(), >> * in the context of the event owner, once, during the event_init(). >> */ >> #define SPE_PMU_HW_FLAGS_CX 0x00001 >> @@ -50,7 +50,7 @@ static_assert((PERF_EVENT_FLAG_ARCH & SPE_PMU_HW_FLAGS_CX) == SPE_PMU_HW_FLAGS_C >> >> static void set_spe_event_has_cx(struct perf_event *event) >> { >> - if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && perfmon_capable()) >> + if (IS_ENABLED(CONFIG_PID_IN_CONTEXTIDR) && !perf_allow_kernel(&event->attr)) >> event->hw.flags |= SPE_PMU_HW_FLAGS_CX; > > The rationale for this change in the commit message is because other > drivers gate PERF_SAMPLE_PHYS_ADDR on perf_allow_kernel(). However, > putting the PID in contextidr doesn't seem to have anything to do with > that... > That is true, I suppose I was thinking of two reasons to do it this way that I didn't really elaborate on: #1 because context IDs and physical timestamps didn't seem to be any more sensitive than physical addresses, so it wouldn't make sense for them to have a stricter permissions model than addresses. #2 (although this is indirect and not really related to the driver) but Perf will still print the misleading warning when physical timestamps are requested. So some other fix would eventually have to be made for that. I'm not sure if you are objecting to the permissions change for the other two things, or it's just a lack of reasoning in the commit message? IMO if we think the other two can't be changed, I would actually rather drop the change than only target PERF_SAMPLE_PHYS_ADDR. Because that seems like it unnecessarily complicates the permissions and might be quite surprising to a user. And then maybe some attempt of a fix could be made in Perf instead. Although that could be difficult because of the lack of a specific error code from the driver. >> } >> >> @@ -745,9 +745,8 @@ static int arm_spe_pmu_event_init(struct perf_event *event) >> >> set_spe_event_has_cx(event); >> reg = arm_spe_event_to_pmscr(event); >> - if (!perfmon_capable() && >> - (reg & (PMSCR_EL1_PA | PMSCR_EL1_PCT))) >> - return -EACCES; >> + if (reg & (PMSCR_EL1_PA | PMSCR_EL1_PCT)) > > Similarly here. What does the physical counter have to do with physical > address sampling other than sharing the word "physical"? > > Will