From: Vince Weaver <vincent.weaver@maine.edu>
To: Andrew Kilroy <andrew.kilroy@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
acme@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>, Tom Rix <trix@redhat.com>,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
bpf@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH 2/8] perf evsel: Do not request ptrauth sample field if not supported
Date: Wed, 6 Jul 2022 12:01:11 -0400 (EDT) [thread overview]
Message-ID: <d67dff7-73c3-e5a-eb7b-f132e8f565cc@maine.edu> (raw)
In-Reply-To: <20220704145333.22557-3-andrew.kilroy@arm.com>
On Mon, 4 Jul 2022, Andrew Kilroy wrote:
> A subsequent patch alters perf to perf_event_open with the
> PERF_SAMPLE_ARCH_1 bit on.
>
> This patch deals with the case where the kernel does not know about the
> PERF_SAMPLE_ARCH_1 bit, and does not know to send the pointer
> authentication masks. In this case the perf_event_open system call
> returns -EINVAL (-22) and perf exits with an error.
>
> This patch causes userspace process to re-attempt the perf_event_open
> system call but without asking for the PERF_SAMPLE_ARCH_1 sample
> field, allowing the perf_event_open system call to succeed.
So in this case you are leaking ARM64-specific info into the generic
perf_event_open() call? Is there any way the kernel could implement this
without userspace having to deal with the issue?
There are a few recent ARM64 perf_event related patches that are pushing
ARM specific interfaces into the generic code, with the apparent
assumption that it will just be implemented in the userspace perf tool.
However there are a number of outside-the-kernel codebases that also use
perf_event_open() and it seems a bit onerous if all of them have to start
adding a lot of extra ARM64-specific code, especially because as far as I
can tell there haven't been any documentation patches included for the
Makefile.
The other recent change that's annoying for userspace is the addition of
the ARM-specific /proc/sys/kernel/perf_user_access that duplicates
functionality found in /sys/devices/cpu/rdpmc
Vince Weaver
vincent.weaver@maine.edu
next prev parent reply other threads:[~2022-07-06 16:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-04 14:53 [PATCH 0/8] Perf stack unwinding with pointer authentication Andrew Kilroy
2022-07-04 14:53 ` [PATCH 1/8] perf arm64: Send pointer auth masks to ring buffer Andrew Kilroy
2022-08-10 13:23 ` Arnaldo Carvalho de Melo
2022-09-07 15:21 ` James Clark
2022-07-04 14:53 ` [PATCH 2/8] perf evsel: Do not request ptrauth sample field if not supported Andrew Kilroy
2022-07-06 16:01 ` Vince Weaver [this message]
2022-07-11 9:25 ` James Clark
2022-07-12 21:30 ` Vince Weaver
2022-07-04 14:53 ` [PATCH 3/8] perf test: Update arm64 tests to expect ptrauth masks Andrew Kilroy
2022-07-04 14:53 ` [PATCH 4/8] perf tools: arm64: Read ptrauth data from kernel Andrew Kilroy
2022-07-04 14:53 ` [PATCH 5/8] perf libunwind: Feature check for libunwind ptrauth callback Andrew Kilroy
2022-07-04 14:53 ` [PATCH 6/8] perf libunwind: arm64 pointer authentication Andrew Kilroy
2022-07-04 14:53 ` [PATCH 7/8] perf tools: Print ptrauth struct in perf report Andrew Kilroy
2022-07-04 14:53 ` [PATCH 8/8] perf test arm64: Test unwinding with PACs on gcc & clang compilers Andrew Kilroy
2022-09-07 15:00 ` [PATCH 0/8] Perf stack unwinding with pointer authentication James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d67dff7-73c3-e5a-eb7b-f132e8f565cc@maine.edu \
--to=vincent.weaver@maine.edu \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrew.kilroy@arm.com \
--cc=bpf@vger.kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=trix@redhat.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®