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 X-Spam-Level: X-Spam-Status: No, score=-11.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96F24C432BE for ; Fri, 27 Aug 2021 21:11:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7FC3E60EBD for ; Fri, 27 Aug 2021 21:11:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231856AbhH0VL5 (ORCPT ); Fri, 27 Aug 2021 17:11:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:51192 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231570AbhH0VL4 (ORCPT ); Fri, 27 Aug 2021 17:11:56 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 3821B60E78; Fri, 27 Aug 2021 21:11:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630098667; bh=0J24TIWf8un+7BNgVI6ycuS4d2s9YAG3kZ6HY1i/HO0=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=Um3Zag09FUrqeeBy8h8bw/Dq9pfj83Oac5gjtk2iNXPqrbZRBiHAzbJb6Ne+f9mKF dxwifgj7U1VMFioh1/McZPcjNt/H08BTn5z0UGYzJv70mhfjeQ2qvNQoup2k6dBmmb nEvxJCfcWDQwMYszsMOyv3EwycPOruIhvFILTselPDsguTo956zceTgD5/ac8VzrBv hM75CBvFavx+J1j/gcIwvaFNYmWoKJ1ZzdPCdCa2CUG19Q5MyAVQA4Fuy+EwcsOqUS b9qwAChEu3uLyyUYCgMfP0w0xISCnwPx6KnxRfrgFcPhI+/XMlp/WSw8fkhBIVieNK 3RXhLEbuenPSA== Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 5560927C0054; Fri, 27 Aug 2021 17:11:05 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute6.internal (MEProxy); Fri, 27 Aug 2021 17:11:05 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddufedgudehkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpeefheekleetudffieethedtkeegfeevjefgvedugeevgefhtdek jeevhfdutedugfenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhkvghrnhgvlhdroh hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr nhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedukeehieefvd dqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinhhugidrlhhu thhordhush X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2F5CAA0378F; Fri, 27 Aug 2021 17:11:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1125-g685cec594c-fm-20210825.001-g685cec59 Mime-Version: 1.0 Message-Id: <43b3a838-da8a-4733-9832-f3d5f990ec13@www.fastmail.com> In-Reply-To: References: <20210728230230.1911468-1-robh@kernel.org> <20210728230230.1911468-3-robh@kernel.org> Date: Fri, 27 Aug 2021 14:10:42 -0700 From: "Andy Lutomirski" To: "Rob Herring" Cc: "Peter Zijlstra (Intel)" , "Mark Rutland" , "Will Deacon" , "Kan Liang" , "Linux Kernel Mailing List" , "Ingo Molnar" , "Arnaldo Carvalho de Melo" , "Alexander Shishkin" , "Jiri Olsa" , "Namhyung Kim" , "Thomas Gleixner" , "Borislav Petkov" , "the arch/x86 maintainers" , "H. Peter Anvin" , "Dave Hansen" , linux-perf-users@vger.kernel.org Subject: Re: [RFC 2/3] perf/x86: Control RDPMC access from .enable() hook Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 26, 2021, at 12:09 PM, Rob Herring wrote: > On Thu, Aug 26, 2021 at 1:13 PM Andy Lutomirski wrot= e: > > > > > > > > On Thu, Aug 12, 2021, at 11:16 AM, Rob Herring wrote: > > > On Thu, Aug 12, 2021 at 11:50 AM Andy Lutomirski = wrote: > > > > > > > > On 7/28/21 4:02 PM, Rob Herring wrote: > > > > > Rather than controlling RDPMC access behind the scenes from sw= itch_mm(), > > > > > move RDPMC access controls to the PMU .enable() hook. The .ena= ble() hook > > > > > is called whenever the perf CPU or task context changes which = is when > > > > > the RDPMC access may need to change. > > > > > > > > > > This is the first step in moving the RDPMC state tracking out = of the mm > > > > > context to the perf context. > > > > > > > > Is this series supposed to be a user-visible change or not? I'm= confused. > > > > > > It should not be user-visible. Or at least not user-visible for wh= at > > > any user would notice. If an event is not part of the perf context= on > > > another thread sharing the mm, does that thread need rdpmc access?= No > > > access would be a user-visible change, but I struggle with how tha= t's > > > a useful scenario? > > > > > > > This is what I mean by user-visible -- it changes semantics in a way= that a user program could detect. I'm not saying it's a problem, but I= do think you need to document the new semantics. >=20 > After testing some scenarios and finding perf_event_tests[1], this > series isn't going to work for x86 unless rdpmc is restricted to task > events only or allowed to segfault on CPU events when read on the > wrong CPU rather than just returning garbage. It's been discussed > before here[2]. >=20 > Ultimately, I'm just trying to define the behavior for arm64 where we > don't have an existing ABI to maintain and don't have to recreate the > mistakes of x86 rdpmc ABI. Tying the access to mmap is messy. As we > explicitly request user access on perf_event_open(), I think it may be > better to just enable access when the event's context is active and > ignore mmap(). Maybe you have an opinion there since you added the > mmap() part? That makes sense to me. The mmap() part was always a giant kludge. There is fundamentally a race, at least if rseq isn=E2=80=99t used: if y= ou check that you=E2=80=99re on the right CPU, do RDPMC, and throw out t= he result if you were on the wrong CPU (determined by looking at the mma= p), you still would very much prefer not to fault. Maybe rseq or a vDSO helper is the right solution for ARM. >=20 > Rob >=20 > [1] https://github.com/deater/perf_event_tests > [2] https://lore.kernel.org/lkml/alpine.DEB.2.21.1901101229010.3358@ma= cbook-air/ >=20