Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <30d95df2-c3b-b3e3-d65e-c6be0355fb1@maine.edu>
In-Reply-To: <30d95df2-c3b-b3e3-d65e-c6be0355fb1@maine.edu>
From:   Rob Herring <robh@kernel.org>
Date:   Wed, 15 Jun 2022 13:46:35 -0600
Message-ID: <CAL_JsqL+0z1vc+T+9m-faoM-4W=x=7-UBu5=S-QGjTwU2biGNw@mail.gmail.com>
Subject: Re: [perf] why is /proc/sys/kernel/perf_user_access ARM64 only?
To:     Vince Weaver <vincent.weaver@maine.edu>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@redhat.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        linux-perf-users <linux-perf-users@vger.kernel.org>,
        Will Deacon <will@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jun 15, 2022 at 11:57 AM Vince Weaver <vincent.weaver@maine.edu> wrote:
>
>
> Just wasted a lot of time tracking down why rdpmc() event reading wasn't
> working on an ARM64 machine.
>
> It turns out ARM64 has added a custom
>         "/proc/sys/kernel/perf_user_access"
> to control rdpmc access, but only on ARM64.
>         e2012600810c9ded81f6f63a8d04781be3c300ad
>
> Why is this ARM64-only?  Why isn't this generic perf infrastructure?

Adding it on x86 would break users at least if default off.

> How is this different from the existing
>         /sys/bus/event_source/devices/cpu/rdpmc
> tooling?

big.LITTLE

We need a single point of control. Otherwise, there's dealing with
mismatched state of multiple PMUs.

> Also, when user events are disabled, why is the ARMv8 PMU not disabling
> the cap_user_rdpmc bit in the perf mmap() page?

Humm, maybe that should be changed. The current behavior of
cap_user_rdpmc is static for the event and set means user access may
be enabled at some point. Several factors can still prevent userspace
from getting an event index. A counter couldn't be allocated or
perf_user_access is disabled.

Should the event open fail if perf_user_access is disabled? Current
operation is it isn't considered and perf_user_access can change while
the event is opened.

> rdpmc was trouble before, but now it's an even bigger
> architecture-dependent mess just trying to figure out if the feature is
> enabled or not.

The thing is that x86 started with access being wide open and has
since been trying to lock things down without breaking userspace. It
still has questionable uses enabled which complicates the
implementation. For arm, we're starting with access being an explicit
request on open and only for task bound events. If there's a real need
for other scenarios, then we can revisit that.

Rob