From: David Vernet <void@manifault.com>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, song@kernel.org, yhs@meta.com,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org,
linux-kernel@vger.kernel.org, kernel-team@meta.com,
memxor@gmail.com
Subject: [PATCH bpf-next v2 1/3] bpf: Add BPF_KFUNC macro for defining kfuncs
Date: Mon, 23 Jan 2023 11:15:04 -0600 [thread overview]
Message-ID: <20230123171506.71995-2-void@manifault.com> (raw)
In-Reply-To: <20230123171506.71995-1-void@manifault.com>
kfuncs are functions defined in the kernel, which may be invoked by BPF
programs. They may or may not also be used as regular kernel functions,
implying that they may be static (in which case the compiler could e.g.
inline it away), or it could have external linkage, but potentially be
elided in an LTO build if a function is observed to never be used, and
is stripped from the final kernel binary.
We therefore require some convenience macro that kfunc developers can
use when defining a kfunc, and which will prevent all of the above
issues from happening. This is in contrast with what we have today,
where some kfunc definitions have "noinline", some have "__used", and
others are static and have neither.
In addition to providing the obvious correctness benefits, having such a
macro also provides an easy way to query for if kfuncs, as Christoph
suggested at the kernel maintainers summit
(https://lwn.net/Articles/908464/). This is currently possible by
grepping for BTF_ID_FLAGS(func, but having something more self
describing is useful.
Note that checkpatch complains about this patch with the following:
ERROR: Macros with multiple statements should be enclosed in a do - while loop
+#define BPF_KFUNC(proto) \
+ proto; \
+ __used noinline proto
Given that we're wrapping the function definition and also including its
prototype, using do { } while(0) isn't an option. Hopefully it's
therefore inappropriate to ignore the warning.
Signed-off-by: David Vernet <void@manifault.com>
---
include/linux/btf.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/linux/btf.h b/include/linux/btf.h
index 5f628f323442..593a1c2615e7 100644
--- a/include/linux/btf.h
+++ b/include/linux/btf.h
@@ -72,6 +72,16 @@
#define KF_DESTRUCTIVE (1 << 6) /* kfunc performs destructive actions */
#define KF_RCU (1 << 7) /* kfunc only takes rcu pointer arguments */
+/*
+ * Macro for defining a kfunc. This is meant to minimize the amount of
+ * copy-paste that kfunc authors have to include for correctness so as to avoid
+ * issues such as the compiler inlining or eliding either a static kfunc, or a
+ * global kfunc in an LTO build.
+ */
+#define BPF_KFUNC(proto) \
+ proto; \
+ __used noinline proto
+
/*
* Return the name of the passed struct, if exists, or halt the build if for
* example the structure gets renamed. In this way, developers have to revisit
--
2.39.0
next prev parent reply other threads:[~2023-01-23 17:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 17:15 [PATCH bpf-next v2 0/3] Add BPF_KFUNC macro for kfunc definitions David Vernet
2023-01-23 17:15 ` David Vernet [this message]
2023-01-23 17:15 ` [PATCH bpf-next v2 2/3] bpf: Document usage of the new BPF_KFUNC macro David Vernet
2023-01-23 17:15 ` [PATCH bpf-next v2 3/3] bpf: Use BPF_KFUNC macro at all kfunc definitions David Vernet
2023-01-23 18:33 ` Alexei Starovoitov
2023-01-23 18:48 ` David Vernet
2023-01-23 18:54 ` Alexei Starovoitov
2023-01-23 19:01 ` David Vernet
2023-01-23 19:04 ` Daniel Borkmann
2023-01-23 21:00 ` Jonathan Corbet
2023-01-24 0:54 ` David Vernet
2023-01-24 14:50 ` Jonathan Corbet
2023-01-24 16:20 ` David Vernet
2023-01-31 15:15 ` Alan Maguire
2023-01-31 15:44 ` David Vernet
2023-01-31 17:30 ` Alexei Starovoitov
2023-01-23 19:01 ` kernel test robot
2023-01-23 19:12 ` kernel test robot
2023-01-24 7:15 ` Christoph Hellwig
2023-01-24 14:15 ` David Vernet
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=20230123171506.71995-2-void@manifault.com \
--to=void@manifault.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=yhs@meta.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