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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 A944CC4320E for ; Mon, 30 Aug 2021 20:21:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8A46B60240 for ; Mon, 30 Aug 2021 20:21:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235141AbhH3UWS (ORCPT ); Mon, 30 Aug 2021 16:22:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233129AbhH3UWQ (ORCPT ); Mon, 30 Aug 2021 16:22:16 -0400 Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AA4BC061575 for ; Mon, 30 Aug 2021 13:21:22 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id 2so8250364qtw.1 for ; Mon, 30 Aug 2021 13:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=maine.edu; s=google; h=from:date:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=X7a3OV8CJpHOBd/pCAOp/2UFjX6RkqdkX1D3kGcsPcE=; b=M+fTkpA41Uub+mOaSv7kcWaeQm3vIscRWIMBMqoISpojyDuGEmCULgvUOgsdSLmmxD a9lAGZaWrL3v0Li5+QZkgKWpLT0K75/AZGUzifyvsOaF9WUNY0q5sk/eSpHNanAYRlp+ 532QwkMUbAR+FiPQw0hDi7p415rdQn7h2gspU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=X7a3OV8CJpHOBd/pCAOp/2UFjX6RkqdkX1D3kGcsPcE=; b=eaTnbNrtnG+A2Qa/4LD5wAy5bquAiitk93HJYWvCwan5TInZ8CekYDDpsQjERxcLi0 rhgcEZeTBLHVyXgD9D0v2r0MwDqFF4x8JdleuF5d0C5BCsiIcuN6q7pBOnVr3dR5nuRu KUxxfWRSNxqzclHcCaInbJKZnOKqpW3TSffZzWJwbn5d2TMWsFEr8qdOoqWexqce8Nh0 mlDtqe9+O9C0ku+JMQhSizxLEBiYp2gSku3wPr0unGnbrICWYyMnzLGqGJK6AWXcv8hc ugrU9TUO1y1HOmWSFe+b3hqRps9ezX3azk7mNUya0JkuaPZ/ghn6W/P9z+CDTexgHNtd lN3Q== X-Gm-Message-State: AOAM530qFGBgHsqrxSFwBFCxYsqhj4IPDuVB7ETj0C2k9yo2biOBrEV1 HphROrtSJNvqVYIZvXRJt9oSKA== X-Google-Smtp-Source: ABdhPJydpWIP492t1UTT5fjbG2zKIIJqZI2UcajFxI7JG8jM6Yunv/Ol884PuqKAJVWyFN1tBYwtpw== X-Received: by 2002:a05:622a:1888:: with SMTP id v8mr22468747qtc.105.1630354881835; Mon, 30 Aug 2021 13:21:21 -0700 (PDT) Received: from macbook-air.local (weaver.eece.maine.edu. [130.111.218.23]) by smtp.gmail.com with ESMTPSA id s28sm11974306qkm.43.2021.08.30.13.21.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 13:21:21 -0700 (PDT) From: Vince Weaver X-Google-Original-From: Vince Weaver Date: Mon, 30 Aug 2021 16:21:19 -0400 (EDT) To: Peter Zijlstra cc: Vince Weaver , Andy Lutomirski , Rob Herring , 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 In-Reply-To: <20210830085106.GF4353@worktop.programming.kicks-ass.net> Message-ID: <0b794c5-5988-c79d-7bb-11533ed92a9@maine.edu> References: <20210728230230.1911468-1-robh@kernel.org> <20210728230230.1911468-3-robh@kernel.org> <43b3a838-da8a-4733-9832-f3d5f990ec13@www.fastmail.com> <20210830085106.GF4353@worktop.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 30 Aug 2021, Peter Zijlstra wrote: > There's just not much we can do to validate the usage, fundamentally at > RDPMC time we're not running any kernel code, so we can't validate the > conditions under which we're called. > > I suppose one way would be to create a mode where RDPMC is disabled but > emulated -- which completely voids the reason for using RDPMC in the > first place (performance), but would allow us to validate the usage. > > Fundamentally, we must call RDPMC only for events that are currently > actuve on *this* CPU. Currently we rely on userspace to DTRT and if it > doesn't we have no way of knowing and it gets to keep the pieces. yes, though it would be nice for cases where things will never work (such as process-attach? I think even if pinned to the same CPU that won't work?) Maybe somehow the mmap page could be set in a way to indicate we should fall back to the syscall. Maybe set pc->index to an invalid value so we can use the existing syscall fallback code. We could force every userspace program to know allthe unsupoorted cases but it seems like it could be easier and less failure-prone to centralize this in the kernel. I was looking into maybe creating a patch for this but the magic perf mmap page implementation is complex enough that I'm not sure I'm qualified to mess with it. Vince