> > Following up on this, I have moved to kernel 5.19.12 and I'm trying to
> > make any kfunc work.
> > I changed net/bpf/test_run.c to allow for more prog types, like master
> > branch does, since originally it only had the first line for
> > BPF_PROG_TYPE_SCHED_CLS.
> >
> > ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS,
> > &bpf_prog_test_kfunc_set);
> > ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING,
> > &bpf_prog_test_kfunc_set);
> > ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_KPROBE,
> > &bpf_prog_test_kfunc_set);
> > ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACEPOINT,
> > &bpf_prog_test_kfunc_set);
> > return ret ?: register_btf_id_dtor_kfuncs(bpf_prog_test_dtor_kfunc,
> > ARRAY_SIZE(bpf_prog_test_dtor_kfunc),
> > THIS_MODULE);
> >
> > I also added my own function to test it out and added it to the SET
> >
> > u64 noinline bpf_kfunc_call_test4(u32 a, u64 b, u32 c, u64 d)
> > {
> > return a + b + c + d;
> > }
> > //this is inside BTF_SET_START(test_sk_check_kfunc_ids)
> > BTF_ID(func, bpf_kfunc_call_test4)
> >
> > Now I'm spraying every BPF program I can find to call either function:
> >
> > extern __u64 bpf_kfunc_call_test1(struct sock *sk, __u32 a, __u64 b,
> > __u32 c, __u64 d) __ksym;
> > extern __u64 bpf_kfunc_call_test4(__u32 a, __u64 b, __u32 c, __u64 d) __ksym;
> >
> > Compiling works, and when I run it I get no errors, *except* Permission denied.
> > gist here: https://gist.github.com/hfingler/5c2c0b713299daa6b0ba07fa92ff29de
> >
> > libbpf: prog 'kfunc_call_test1': BPF program load failed: Permission denied
>
> seems like the kfunc is not found on the set for the program type, I guess
> your change above did not go as expected
>
> not sure what is your goal exactly, but perhaps better than starting from
> scratch would be to take prog_tests/kfunc_call.c and progs/kfunc_call_test.c
> and change them accordingly?
>
> jirka
My goal is to be able to call any kfunc. If I can do that I can add
trampolines to do more interesting things.
Starting from those files is pretty much what I was doing already, but
I started from scratch again.
I was finally able to load the BPF program without the EPERM error. I
think it's working but I'm not sure since I don't know
how to trigger the function so it prints something.
It seems like the error was having multiple calls to
`register_btf_kfunc_id_set` in `net/bpf/test_run.c`. By commenting out
the three
that I added, the function was found on the set and worked correctly.
With the others uncommented, the set find was returning false.
I suppose multiple of these calls do not work on 5.19 but do work on
later versions.
This part of the code on 6.0 (or master) has two calls to
`register_btf_kfunc_id_set` in sequence, but also many changes around
it, like `btf_kfunc_id_set` having only `.set`,
so maybe something was changed on the backend.
ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS,
&bpf_prog_test_kfunc_set);
//ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACING,
&bpf_prog_test_kfunc_set);
//ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_KPROBE,
&bpf_prog_test_kfunc_set);
//ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_TRACEPOINT,
&bpf_prog_test_kfunc_set);
return ret ?: register_btf_id_dtor_kfuncs(bpf_prog_test_dtor_kfunc,
ARRAY_SIZE(bpf_prog_test_dtor_kfunc),
THIS_MODULE);
Before I go at it, are there any immediate restrictions on
BPF_PROG_TYPE_KPROBE calling kfuncs? I'll have to figure out how to do
it, but knowing it *can* work does help.
Thank you.
