From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@fomichev.me>,
Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Jesper Dangaard Brouer <hawk@kernel.org>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [PATCH bpf] bpf: fix configuration-dependent BTF function references
Date: Fri, 13 Dec 2024 00:37:44 +0100 [thread overview]
Message-ID: <a19b5fb2-9a82-42f2-81dd-17d96bb6ec9e@t-8ch.de> (raw)
In-Reply-To: <CAEf4BzYTYDcf7J0jhJP3cW5489jWXdfJcw-f-8yuTHcNmQ0cbw@mail.gmail.com>
On 2024-12-12 15:27:12-0800, Andrii Nakryiko wrote:
> On Thu, Dec 12, 2024 at 3:00 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
> >
> > These BTF functions are not available unconditionally,
> > only reference them when they are available.
> >
> > Avoid the following build warnings:
> >
> > BTF .tmp_vmlinux1.btf.o
> > btf_encoder__tag_kfunc: failed to find kfunc 'bpf_send_signal_task' in BTF
> > btf_encoder__tag_kfuncs: failed to tag kfunc 'bpf_send_signal_task'
> > NM .tmp_vmlinux1.syms
> > KSYMS .tmp_vmlinux1.kallsyms.S
> > AS .tmp_vmlinux1.kallsyms.o
> > LD .tmp_vmlinux2
> > NM .tmp_vmlinux2.syms
> > KSYMS .tmp_vmlinux2.kallsyms.S
> > AS .tmp_vmlinux2.kallsyms.o
> > LD vmlinux
> > BTFIDS vmlinux
> > WARN: resolve_btfids: unresolved symbol prog_test_ref_kfunc
> > WARN: resolve_btfids: unresolved symbol bpf_crypto_ctx
> > WARN: resolve_btfids: unresolved symbol bpf_send_signal_task
> > WARN: resolve_btfids: unresolved symbol bpf_modify_return_test_tp
> > WARN: resolve_btfids: unresolved symbol bpf_dynptr_from_xdp
> > WARN: resolve_btfids: unresolved symbol bpf_dynptr_from_skb
> >
> > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > ---
> > kernel/bpf/helpers.c | 4 ++++
> > kernel/bpf/verifier.c | 8 ++++++++
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > index 751c150f9e1cd7f56e6a2b68a7ebb4ae89a30d2d..5edf5436a7804816b7dcf1bbef2624d71a985f20 100644
> > --- a/kernel/bpf/helpers.c
> > +++ b/kernel/bpf/helpers.c
> > @@ -3089,7 +3089,9 @@ BTF_ID_FLAGS(func, bpf_task_get_cgroup1, KF_ACQUIRE | KF_RCU | KF_RET_NULL)
> > BTF_ID_FLAGS(func, bpf_task_from_pid, KF_ACQUIRE | KF_RET_NULL)
> > BTF_ID_FLAGS(func, bpf_task_from_vpid, KF_ACQUIRE | KF_RET_NULL)
> > BTF_ID_FLAGS(func, bpf_throw)
> > +#ifdef CONFIG_BPF_EVENTS
> > BTF_ID_FLAGS(func, bpf_send_signal_task, KF_TRUSTED_ARGS)
> > +#endif
> > BTF_KFUNCS_END(generic_btf_ids)
> >
> > static const struct btf_kfunc_id_set generic_kfunc_set = {
> > @@ -3135,7 +3137,9 @@ BTF_ID_FLAGS(func, bpf_dynptr_is_null)
> > BTF_ID_FLAGS(func, bpf_dynptr_is_rdonly)
> > BTF_ID_FLAGS(func, bpf_dynptr_size)
> > BTF_ID_FLAGS(func, bpf_dynptr_clone)
> > +#ifdef CONFIG_NET
> > BTF_ID_FLAGS(func, bpf_modify_return_test_tp)
> > +#endif
>
> It makes little sense to have bpf_prog_test_run_tracing() and
> bpf_modify_return_test_tp() depend on CONFIG_NET... It's just
> historically where BPF_PROG_TEST_RUN functionality was implemented,
> but it seems like we need to move bpf_prog_test_run_tracing() and
> other tracing-related testing stuff into kernel/trace/bpf_trace.c or
> somewhere under kernel/bpf/ (core.c? helpers.c?)
I agree. But today these are the config values which are in effect.
When the functions get moved, the config values can be adapted.
With my commit "kbuild/btf: Propagate CONFIG_WERROR to resolve_btfids"
in bpf-next the warnings can actually become errors.
So I'd propose to apply this fix to avoid issues in the near future and
then do a proper move without any urgency.
> > BTF_ID_FLAGS(func, bpf_wq_init)
> > BTF_ID_FLAGS(func, bpf_wq_set_callback_impl)
> > BTF_ID_FLAGS(func, bpf_wq_start)
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 5e541339b2f6d1870561033fd55cca7144db14bc..77bbf58418fee7533bce539c8e005d2342ee1a48 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5526,7 +5526,9 @@ static bool in_rcu_cs(struct bpf_verifier_env *env)
> >
> > /* Once GCC supports btf_type_tag the following mechanism will be replaced with tag check */
> > BTF_SET_START(rcu_protected_types)
> > +#ifdef CONFIG_NET
> > BTF_ID(struct, prog_test_ref_kfunc)
> > +#endif
> > #ifdef CONFIG_CGROUPS
> > BTF_ID(struct, cgroup)
> > #endif
> > @@ -5534,7 +5536,9 @@ BTF_ID(struct, cgroup)
> > BTF_ID(struct, bpf_cpumask)
> > #endif
> > BTF_ID(struct, task_struct)
> > +#ifdef CONFIG_CRYPTO
> > BTF_ID(struct, bpf_crypto_ctx)
> > +#endif
> > BTF_SET_END(rcu_protected_types)
> >
> > static bool rcu_protected_object(const struct btf *btf, u32 btf_id)
> > @@ -11529,8 +11533,10 @@ BTF_ID(func, bpf_rdonly_cast)
> > BTF_ID(func, bpf_rbtree_remove)
> > BTF_ID(func, bpf_rbtree_add_impl)
> > BTF_ID(func, bpf_rbtree_first)
> > +#ifdef CONFIG_NET
> > BTF_ID(func, bpf_dynptr_from_skb)
> > BTF_ID(func, bpf_dynptr_from_xdp)
> > +#endif
> > BTF_ID(func, bpf_dynptr_slice)
> > BTF_ID(func, bpf_dynptr_slice_rdwr)
> > BTF_ID(func, bpf_dynptr_clone)
> > @@ -11558,8 +11564,10 @@ BTF_ID(func, bpf_rcu_read_unlock)
> > BTF_ID(func, bpf_rbtree_remove)
> > BTF_ID(func, bpf_rbtree_add_impl)
> > BTF_ID(func, bpf_rbtree_first)
> > +#ifdef CONFIG_NET
> > BTF_ID(func, bpf_dynptr_from_skb)
> > BTF_ID(func, bpf_dynptr_from_xdp)
> > +#endif
> > BTF_ID(func, bpf_dynptr_slice)
> > BTF_ID(func, bpf_dynptr_slice_rdwr)
> > BTF_ID(func, bpf_dynptr_clone)
> >
> > ---
> > base-commit: 5d287a7de3c95b78946e71d17d15ec9c87fffe7f
> > change-id: 20241212-bpf-cond-ids-9bfbc64dd77b
> >
> > Best regards,
> > --
> > Thomas Weißschuh <linux@weissschuh.net>
> >
next prev parent reply other threads:[~2024-12-12 23:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-12 23:00 Thomas Weißschuh
2024-12-12 23:27 ` Andrii Nakryiko
2024-12-12 23:37 ` Thomas Weißschuh [this message]
2024-12-13 22:37 ` Andrii Nakryiko
2024-12-13 23:10 ` patchwork-bot+netdevbpf
2024-12-18 21:18 ` Alexei Starovoitov
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=a19b5fb2-9a82-42f2-81dd-17d96bb6ec9e@t-8ch.de \
--to=linux@weissschuh.net \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--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
all inboxes | Powered by JetHome®