mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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>
> >

  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®