From: Ingo Molnar <mingo@kernel.org>
To: Kyle Huey <me@kylehuey.com>
Cc: Kyle Huey <khuey@kylehuey.com>,
linux-kernel@vger.kernel.org,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Marco Elver <elver@google.com>,
Yonghong Song <yonghong.song@linux.dev>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Robert O'Callahan <robert@ocallahan.org>,
Song Liu <song@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
linux-perf-users@vger.kernel.org, bpf@vger.kernel.org
Subject: Re: [RESEND PATCH v5 1/4] perf/bpf: Call bpf handler directly, not through overflow machinery
Date: Wed, 10 Apr 2024 06:31:56 +0200 [thread overview]
Message-ID: <ZhYWPGX0RzamxOHx@gmail.com> (raw)
In-Reply-To: <20240214173950.18570-2-khuey@kylehuey.com>
* Kyle Huey <me@kylehuey.com> wrote:
> To ultimately allow bpf programs attached to perf events to completely
> suppress all of the effects of a perf event overflow (rather than just the
> sample output, as they do today), call bpf_overflow_handler() from
> __perf_event_overflow() directly rather than modifying struct perf_event's
> overflow_handler. Return the bpf program's return value from
> bpf_overflow_handler() so that __perf_event_overflow() knows how to
> proceed. Remove the now unnecessary orig_overflow_handler from struct
> perf_event.
>
> This patch is solely a refactoring and results in no behavior change.
>
> Signed-off-by: Kyle Huey <khuey@kylehuey.com>
> Suggested-by: Namhyung Kim <namhyung@kernel.org>
> Acked-by: Song Liu <song@kernel.org>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
> ---
> include/linux/perf_event.h | 6 +-----
> kernel/events/core.c | 28 +++++++++++++++-------------
> 2 files changed, 16 insertions(+), 18 deletions(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index d2a15c0c6f8a..c7f54fd74d89 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -810,7 +810,6 @@ struct perf_event {
> perf_overflow_handler_t overflow_handler;
> void *overflow_handler_context;
> #ifdef CONFIG_BPF_SYSCALL
> - perf_overflow_handler_t orig_overflow_handler;
> struct bpf_prog *prog;
> u64 bpf_cookie;
> #endif
Could we reduce the #ifdeffery please?
On distros CONFIG_BPF_SYSCALL is almost always enabled, so it's not like
this truly saves anything on real systems.
I'd suggest making the perf_event::prog and perf_event::bpf_cookie fields
unconditional.
> +#ifdef CONFIG_BPF_SYSCALL
> +static int bpf_overflow_handler(struct perf_event *event,
> + struct perf_sample_data *data,
> + struct pt_regs *regs);
> +#endif
If the function definitions are misordered then first do a patch that moves
the function earlier in the file, instead of slapping a random prototype
into a random place.
> - READ_ONCE(event->overflow_handler)(event, data, regs);
> +#ifdef CONFIG_BPF_SYSCALL
> + if (!(event->prog && !bpf_overflow_handler(event, data, regs)))
> +#endif
> + READ_ONCE(event->overflow_handler)(event, data, regs);
This #ifdef would go away too - on !CONFIG_BPF_SYSCALL event->prog should
always be NULL.
Please keep the #ifdeffery reduction and function-moving patches separate
from these other changes.
Thanks,
Ingo
next prev parent reply other threads:[~2024-04-10 4:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240214173950.18570-1-khuey@kylehuey.com>
2024-02-14 17:39 ` [RESEND PATCH v5 1/4] perf/bpf: Call bpf handler directly, not through overflow machinery Kyle Huey
2024-02-16 0:11 ` Andrii Nakryiko
2024-04-10 4:31 ` Ingo Molnar [this message]
2024-04-11 12:11 ` Kyle Huey
2024-04-12 1:47 ` Kyle Huey
2024-02-14 17:39 ` [RESEND PATCH v5 2/4] perf/bpf: Remove unneeded uses_default_overflow_handler Kyle Huey
2024-02-16 0:12 ` Andrii Nakryiko
2024-04-10 4:35 ` Ingo Molnar
2024-02-14 17:39 ` [RESEND PATCH v5 3/4] perf/bpf: Allow a bpf program to suppress all sample side effects Kyle Huey
2024-02-16 0:13 ` Andrii Nakryiko
2024-02-16 1:59 ` Kyle Huey
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=ZhYWPGX0RzamxOHx@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=elver@google.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=khuey@kylehuey.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=me@kylehuey.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=robert@ocallahan.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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;
as well as URLs for NNTP newsgroup(s).