[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bix2uwya2mnk2vgno3vkdpg5kyusq763bmfj2ov6zwpbva6q4h@nqgm3vk4byh5>
Date: Thu, 4 Jan 2024 18:17:50 -0700
From: Daniel Xu <dxu@...uu.xyz>
To: Jiri Olsa <olsajiri@...il.com>
Cc: benjamin.tissoires@...hat.com, hawk@...nel.org, edumazet@...gle.com,
alexandre.torgue@...s.st.com, ebiggers@...nel.org, tj@...nel.org,
rostedt@...dmis.org, shuah@...nel.org, martin.lau@...ux.dev,
ast@...nel.org, fw@...len.de, kuba@...nel.org, pablo@...filter.org,
jikos@...nel.org, john.fastabend@...il.com, mcoquelin.stm32@...il.com,
mhiramat@...nel.org, yonghong.song@...ux.dev,
Herbert Xu <herbert@...dor.apana.org.au>, dsahern@...nel.org,
hannes@...xchg.org, lizefan.x@...edance.com, pabeni@...hat.com,
steffen.klassert@...unet.com, daniel@...earbox.net, tytso@....edu,
andrii@...nel.org, davem@...emloft.net, kadlec@...filter.org,
song@...nel.org, alexei.starovoitov@...il.com, quentin@...valent.com,
alan.maguire@...cle.com, memxor@...il.com, kpsingh@...nel.org,
sdf@...gle.com, haoluo@...gle.com, mathieu.desnoyers@...icios.com,
mykolal@...com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, fsverity@...ts.linux.dev,
bpf@...r.kernel.org, cgroups@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org,
linux-kselftest@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH bpf-next 2/2] bpf: treewide: Annotate BPF kfuncs in BTF
Hi Jiri,
On Thu, Jan 04, 2024 at 12:41:51PM +0100, Jiri Olsa wrote:
> On Wed, Jan 03, 2024 at 04:31:56PM -0700, Daniel Xu wrote:
>
> SNIP
>
> > diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
> > index 88f914579fa1..771e29762a2d 100644
> > --- a/include/linux/btf_ids.h
> > +++ b/include/linux/btf_ids.h
> > @@ -8,6 +8,9 @@ struct btf_id_set {
> > u32 ids[];
> > };
> >
> > +/* This flag implies BTF_SET8 holds kfunc(s) */
> > +#define BTF_SET8_KFUNC (1 << 0)
> > +
> > struct btf_id_set8 {
> > u32 cnt;
> > u32 flags;
> > diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> > index 51e8b4bee0c8..b8ba00a4179f 100644
> > --- a/kernel/bpf/btf.c
> > +++ b/kernel/bpf/btf.c
> > @@ -7769,6 +7769,9 @@ static int __register_btf_kfunc_id_set(enum btf_kfunc_hook hook,
> > struct btf *btf;
> > int ret, i;
> >
> > + /* All kfuncs need to be tagged as such in BTF */
> > + WARN_ON(!(kset->set->flags & BTF_SET8_KFUNC));
>
> __register_btf_kfunc_id_set gets called also from the 'hooks' path:
>
> bpf_mptcp_kfunc_init
> register_btf_fmodret_id_set
> __register_btf_kfunc_id_set
>
> so it will hit the warn.. it should be probably in the register_btf_kfunc_id_set ?
Yeah, good catch.
>
> also given that we can have modules calling register_btf_kfunc_id_set,
> should we just return error instead of the warn?
It looks like quite a few registrations go through late_initcall(),
in which error codes are thrown away. I'm looking at
init/main.c:do_initcall_level:
for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
do_one_initcall(initcall_from_entry(fn));
Higher level question: if out of tree module does not follow convention,
it would still make sense to WARN(), right?
>
> SNIP
>
> > diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > index 91907b321f91..32972334cd50 100644
> > --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> > @@ -341,7 +341,7 @@ static struct bin_attribute bin_attr_bpf_testmod_file __ro_after_init = {
> > .write = bpf_testmod_test_write,
> > };
> >
> > -BTF_SET8_START(bpf_testmod_common_kfunc_ids)
> > +BTF_SET8_START(bpf_testmod_common_kfunc_ids, BTF_SET8_KFUNC)
> > BTF_ID_FLAGS(func, bpf_iter_testmod_seq_new, KF_ITER_NEW)
> > BTF_ID_FLAGS(func, bpf_iter_testmod_seq_next, KF_ITER_NEXT | KF_RET_NULL)
> > BTF_ID_FLAGS(func, bpf_iter_testmod_seq_destroy, KF_ITER_DESTROY)
>
> we need to change also bpf_testmod_check_kfunc_ids set
Good catch, thanks.
Daniel
Powered by blists - more mailing lists