| Message ID | 20210325015124.1543397-1-kafai@fb.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | bpf: Support calling kernel function | expand |
Hello: This series was applied to bpf/bpf-next.git (refs/heads/master): On Wed, 24 Mar 2021 18:51:24 -0700 you wrote: > This series adds support to allow bpf program calling kernel function. > > The use case included in this set is to allow bpf-tcp-cc to directly > call some tcp-cc helper functions (e.g. "tcp_cong_avoid_ai()"). Those > functions have already been used by some kernel tcp-cc implementations. > > This set will also allow the bpf-tcp-cc program to directly call the > kernel tcp-cc implementation, For example, a bpf_dctcp may only want to > implement its own dctcp_cwnd_event() and reuse other dctcp_*() directly > from the kernel tcp_dctcp.c instead of reimplementing (or > copy-and-pasting) them. > > [...] Here is the summary with links: - [v2,bpf-next,01/14] bpf: Simplify freeing logic in linfo and jited_linfo https://git.kernel.org/bpf/bpf-next/c/e16301fbe183 - [v2,bpf-next,02/14] bpf: Refactor btf_check_func_arg_match https://git.kernel.org/bpf/bpf-next/c/34747c412041 - [v2,bpf-next,03/14] bpf: Support bpf program calling kernel function https://git.kernel.org/bpf/bpf-next/c/e6ac2450d6de - [v2,bpf-next,04/14] bpf: Support kernel function call in x86-32 https://git.kernel.org/bpf/bpf-next/c/797b84f727bc - [v2,bpf-next,05/14] tcp: Rename bictcp function prefix to cubictcp https://git.kernel.org/bpf/bpf-next/c/d22f6ad18709 - [v2,bpf-next,06/14] bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc https://git.kernel.org/bpf/bpf-next/c/e78aea8b2170 - [v2,bpf-next,07/14] libbpf: Refactor bpf_object__resolve_ksyms_btf_id https://git.kernel.org/bpf/bpf-next/c/933d1aa32409 - [v2,bpf-next,08/14] libbpf: Refactor codes for finding btf id of a kernel symbol https://git.kernel.org/bpf/bpf-next/c/774e132e83d0 - [v2,bpf-next,09/14] libbpf: Rename RELO_EXTERN to RELO_EXTERN_VAR https://git.kernel.org/bpf/bpf-next/c/0c091e5c2d37 - [v2,bpf-next,10/14] libbpf: Record extern sym relocation first https://git.kernel.org/bpf/bpf-next/c/aa0b8d43e953 - [v2,bpf-next,11/14] libbpf: Support extern kernel function https://git.kernel.org/bpf/bpf-next/c/5bd022ec01f0 - [v2,bpf-next,12/14] bpf: selftests: Rename bictcp to bpf_cubic https://git.kernel.org/bpf/bpf-next/c/39cd9e0f6783 - [v2,bpf-next,13/14] bpf: selftests: bpf_cubic and bpf_dctcp calling kernel functions https://git.kernel.org/bpf/bpf-next/c/78e60bbbe8e8 - [v2,bpf-next,14/14] bpf: selftests: Add kfunc_call test https://git.kernel.org/bpf/bpf-next/c/7bd1590d4eba You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Hi, On Wed, Mar 24, 2021 at 8:40 PM Martin KaFai Lau <kafai@fb.com> wrote: > Martin KaFai Lau (14): > bpf: Simplify freeing logic in linfo and jited_linfo > bpf: Refactor btf_check_func_arg_match > bpf: Support bpf program calling kernel function > bpf: Support kernel function call in x86-32 > tcp: Rename bictcp function prefix to cubictcp > bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc I got the following link error which is likely caused by one of your patches in this series. FAILED unresolved symbol cubictcp_state make: *** [Makefile:1199: vmlinux] Error 255 Thanks.
On Sat, Mar 27, 2021 at 2:25 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > Hi, > > On Wed, Mar 24, 2021 at 8:40 PM Martin KaFai Lau <kafai@fb.com> wrote: > > Martin KaFai Lau (14): > > bpf: Simplify freeing logic in linfo and jited_linfo > > bpf: Refactor btf_check_func_arg_match > > bpf: Support bpf program calling kernel function > > bpf: Support kernel function call in x86-32 > > tcp: Rename bictcp function prefix to cubictcp > > bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc > > I got the following link error which is likely caused by one of your > patches in this series. > > FAILED unresolved symbol cubictcp_state > make: *** [Makefile:1199: vmlinux] Error 255 I don't see it and bpf CI doesn't see it either. Without steps to reproduce your observation isn't helpful.
On Sat, Mar 27, 2021 at 2:28 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Sat, Mar 27, 2021 at 2:25 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > > Hi, > > > > On Wed, Mar 24, 2021 at 8:40 PM Martin KaFai Lau <kafai@fb.com> wrote: > > > Martin KaFai Lau (14): > > > bpf: Simplify freeing logic in linfo and jited_linfo > > > bpf: Refactor btf_check_func_arg_match > > > bpf: Support bpf program calling kernel function > > > bpf: Support kernel function call in x86-32 > > > tcp: Rename bictcp function prefix to cubictcp > > > bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc > > > > I got the following link error which is likely caused by one of your > > patches in this series. > > > > FAILED unresolved symbol cubictcp_state > > make: *** [Makefile:1199: vmlinux] Error 255 > > I don't see it and bpf CI doesn't see it either. > Without steps to reproduce your observation isn't helpful. Just `make` is sufficient to reproduce it here: # make CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool DESCEND bpf/resolve_btfids CHK include/generated/compile.h GEN .version CHK include/generated/compile.h UPD include/generated/compile.h CC init/version.o AR init/built-in.a LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.btf BTF .btf.vmlinux.bin.o LD .tmp_vmlinux.kallsyms1 KSYMS .tmp_vmlinux.kallsyms1.S AS .tmp_vmlinux.kallsyms1.S LD .tmp_vmlinux.kallsyms2 KSYMS .tmp_vmlinux.kallsyms2.S AS .tmp_vmlinux.kallsyms2.S LD vmlinux BTFIDS vmlinux FAILED unresolved symbol cubictcp_state make: *** [Makefile:1199: vmlinux] Error 255 I suspect it is related to the kernel config or linker version. # grep TCP_CONG .config CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_NV=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m CONFIG_TCP_CONG_DCTCP=m CONFIG_TCP_CONG_CDG=m CONFIG_TCP_CONG_BBR=m CONFIG_DEFAULT_TCP_CONG="cubic" # gcc --version gcc (Debian 8.3.0-6) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # pahole --version v1.17 Also, reverting this whole patchset also makes it go away. Thanks.
On Sat, Mar 27, 2021 at 3:08 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > BTFIDS vmlinux > FAILED unresolved symbol cubictcp_state > make: *** [Makefile:1199: vmlinux] Error 255 > > I suspect it is related to the kernel config or linker version. > > # grep TCP_CONG .config > CONFIG_TCP_CONG_ADVANCED=y > CONFIG_TCP_CONG_BIC=m > CONFIG_TCP_CONG_CUBIC=y .. > > # pahole --version > v1.17 That is the most likely reason. In lib/Kconfig.debug we have pahole >= 1.19 requirement for BTF in modules. Though your config has CUBIC=y I suspect something odd goes on. Could you please try the latest pahole 1.20 ?
On Sat, Mar 27, 2021 at 3:54 PM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Sat, Mar 27, 2021 at 3:08 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > BTFIDS vmlinux > > FAILED unresolved symbol cubictcp_state > > make: *** [Makefile:1199: vmlinux] Error 255 > > > > I suspect it is related to the kernel config or linker version. > > > > # grep TCP_CONG .config > > CONFIG_TCP_CONG_ADVANCED=y > > CONFIG_TCP_CONG_BIC=m > > CONFIG_TCP_CONG_CUBIC=y > .. > > > > # pahole --version > > v1.17 > > That is the most likely reason. > In lib/Kconfig.debug > we have pahole >= 1.19 requirement for BTF in modules. > Though your config has CUBIC=y I suspect something odd goes on. > Could you please try the latest pahole 1.20 ? Sure, I will give it a try tomorrow, I am not in control of the CI I ran. Thanks.
On Sun, Mar 28, 2021 at 01:13:35PM -0700, Cong Wang wrote: > On Sat, Mar 27, 2021 at 3:54 PM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Sat, Mar 27, 2021 at 3:08 PM Cong Wang <xiyou.wangcong@gmail.com> wrote: > > > BTFIDS vmlinux > > > FAILED unresolved symbol cubictcp_state > > > make: *** [Makefile:1199: vmlinux] Error 255 > > > > > > I suspect it is related to the kernel config or linker version. > > > > > > # grep TCP_CONG .config > > > CONFIG_TCP_CONG_ADVANCED=y > > > CONFIG_TCP_CONG_BIC=m > > > CONFIG_TCP_CONG_CUBIC=y > > .. > > > > > > # pahole --version > > > v1.17 > > > > That is the most likely reason. > > In lib/Kconfig.debug > > we have pahole >= 1.19 requirement for BTF in modules. > > Though your config has CUBIC=y I suspect something odd goes on. > > Could you please try the latest pahole 1.20 ? > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it is not set?
On Mon, 29 Mar 2021 at 02:25, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > # pahole --version > > > > v1.17 > > > > > > That is the most likely reason. > > > In lib/Kconfig.debug > > > we have pahole >= 1.19 requirement for BTF in modules. > > > Though your config has CUBIC=y I suspect something odd goes on. > > > Could you please try the latest pahole 1.20 ? > > > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > is not set? I hit the same problem on newer pahole: $ pahole --version v1.20 CONFIG_DYNAMIC_FTRACE=y resolves the issue.
On Mon, Mar 29, 2021 at 05:06:26PM +0100, Lorenz Bauer wrote: > On Mon, 29 Mar 2021 at 02:25, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > > > # pahole --version > > > > > v1.17 > > > > > > > > That is the most likely reason. > > > > In lib/Kconfig.debug > > > > we have pahole >= 1.19 requirement for BTF in modules. > > > > Though your config has CUBIC=y I suspect something odd goes on. > > > > Could you please try the latest pahole 1.20 ? > > > > > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. > > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > > is not set? > > I hit the same problem on newer pahole: > > $ pahole --version > v1.20 > > CONFIG_DYNAMIC_FTRACE=y resolves the issue. Thanks for checking. pahole only generates the btf_id for external function and ftrace-able function. Some functions in the bpf_tcp_ca_kfunc_ids list are static (e.g. cubictcp_init), so it fails during resolve_btfids. I will post a patch to limit the bpf_tcp_ca_kfunc_ids list to CONFIG_DYNAMIC_FTRACE. I will address the pahole generation in a followup and then remove this CONFIG_DYNAMIC_FTRACE limitation.
On Sun, Mar 28, 2021 at 6:24 PM Martin KaFai Lau <kafai@fb.com> wrote: > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > is not set? On my side, with pahole==1.17, changing CONFIG_DYNAMIC_FTRACE makes no difference. With pahole==1.20, CONFIG_DYNAMIC_FTRACE=y makes it gone, but CONFIG_DYNAMIC_FTRACE=n not. Thanks.
On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > This series adds support to allow bpf program calling kernel function. I think there are more build problems with this. Has anyone hit this before? $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 Error: failed to open BPF object file: No such file or directory make: *** [Makefile:453: /home/lorenz/dev/kbuild/vm//no_alu32/bpf_cubic.skel.h] Error 255 make: *** Deleting file '/home/lorenz/dev/kbuild/vm//no_alu32/bpf_cubic.skel.h' make: *** Waiting for unfinished jobs.... libbpf: failed to find BTF for extern 'tcp_reno_cong_avoid' [38] section: -2 Error: failed to open BPF object file: No such file or directory make: *** [Makefile:451: /home/lorenz/dev/kbuild/vm//no_alu32/bpf_dctcp.skel.h] Error 255 make: *** Deleting file '/home/lorenz/dev/kbuild/vm//no_alu32/bpf_dctcp.skel.h'
On Tue, Mar 30, 2021 at 2:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > > > This series adds support to allow bpf program calling kernel function. > > I think there are more build problems with this. Has anyone hit this before? > > $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 > > GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h > GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h > GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h > libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 > Error: failed to open BPF object file: No such file or directory The doc update is on its way: https://patchwork.kernel.org/project/netdevbpf/patch/20210330054156.2933804-1-kafai@fb.com/
On Tue, Mar 30, 2021 at 7:36 AM Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote: > > On Tue, Mar 30, 2021 at 2:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > This series adds support to allow bpf program calling kernel function. > > > > I think there are more build problems with this. Has anyone hit this before? > > > > $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 > > > > GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h > > GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h > > GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h > > libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 > > Error: failed to open BPF object file: No such file or directory > > The doc update is on its way: > https://patchwork.kernel.org/project/netdevbpf/patch/20210330054156.2933804-1-kafai@fb.com/ We just updated our clang to 13, and I still get the same error above. Thanks.
On Tue, Mar 30, 2021 at 12:58:22PM -0700, Cong Wang wrote: > On Tue, Mar 30, 2021 at 7:36 AM Alexei Starovoitov > <alexei.starovoitov@gmail.com> wrote: > > > > On Tue, Mar 30, 2021 at 2:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > > > On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > This series adds support to allow bpf program calling kernel function. > > > > > > I think there are more build problems with this. Has anyone hit this before? > > > > > > $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 > > > > > > GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h > > > GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h > > > GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h > > > libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 > > > Error: failed to open BPF object file: No such file or directory > > > > The doc update is on its way: > > https://patchwork.kernel.org/project/netdevbpf/patch/20210330054156.2933804-1-kafai@fb.com/ > > We just updated our clang to 13, and I still get the same error above. Please check if the llvm/clang has this diff https://reviews.llvm.org/D93563
Hi Martin, I am working with Cong to get Clang/LLVM-13 to test. But I am confused whether CLANG/LLVM-13 is released or not. From https://apt.llvm.org/ , I saw llvm-13 was released in Feb, but it does not have the diff you mentioned. From the following links, I am not sure if LLVM-13 was really released or still in the process. https://llvm.org/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-13 https://github.com/llvm/llvm-project/releases Did I miss something? Where could I get a good clang/llvm-13 ? Or maybe clang-14? Thanks Regards, Jiang On Tue, Mar 30, 2021 at 2:43 PM Martin KaFai Lau <kafai@fb.com> wrote: > > On Tue, Mar 30, 2021 at 12:58:22PM -0700, Cong Wang wrote: > > On Tue, Mar 30, 2021 at 7:36 AM Alexei Starovoitov > > <alexei.starovoitov@gmail.com> wrote: > > > > > > On Tue, Mar 30, 2021 at 2:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > > > > > On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > This series adds support to allow bpf program calling kernel function. > > > > > > > > I think there are more build problems with this. Has anyone hit this before? > > > > > > > > $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 > > > > > > > > GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h > > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > > GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h > > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > > GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h > > > > GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h > > > > GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h > > > > libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 > > > > Error: failed to open BPF object file: No such file or directory > > > > > > The doc update is on its way: > > > https://patchwork.kernel.org/project/netdevbpf/patch/20210330054156.2933804-1-kafai@fb.com/ > > > > We just updated our clang to 13, and I still get the same error above. > Please check if the llvm/clang has this diff > https://reviews.llvm.org/D93563
On Tue, Mar 30, 2021 at 08:28:34PM -0700, Jiang Wang . wrote: > I am working with Cong to get Clang/LLVM-13 to test. But I am confused > whether CLANG/LLVM-13 is released or not. > > From https://apt.llvm.org/ , I saw llvm-13 was released in Feb, but it > does not have the diff you mentioned. I haven't used the Debian/Ubuntu nightly packages, so don't know. > > From the following links, I am not sure if LLVM-13 was really released > or still in the process. > https://llvm.org/docs/ReleaseNotes.html#external-open-source-projects-using-llvm-13 > https://github.com/llvm/llvm-project/releases AFAIK, it is not released, so please directly clone from the llvm-project as also suggested earlier by Pedro. Please refer to the "how do I build LLVM" in Documentation/bpf/bpf_devel_QA.rst. [ Please do not top post. Reply inline instead. It will be difficult for others to follow. ] > On Tue, Mar 30, 2021 at 2:43 PM Martin KaFai Lau <kafai@fb.com> wrote: > > > > On Tue, Mar 30, 2021 at 12:58:22PM -0700, Cong Wang wrote: > > > On Tue, Mar 30, 2021 at 7:36 AM Alexei Starovoitov > > > <alexei.starovoitov@gmail.com> wrote: > > > > > > > > On Tue, Mar 30, 2021 at 2:43 AM Lorenz Bauer <lmb@cloudflare.com> wrote: > > > > > > > > > > On Thu, 25 Mar 2021 at 01:52, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > > > This series adds support to allow bpf program calling kernel function. > > > > > > > > > > I think there are more build problems with this. Has anyone hit this before? > > > > > > > > > > $ CLANG=clang-12 O=../kbuild/vm ./tools/testing/selftests/bpf/vmtest.sh -j 7 > > > > > > > > > > GEN-SKEL [test_progs-no_alu32] bind6_prog.skel.h > > > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > > > GEN-SKEL [test_progs-no_alu32] bind_perm.skel.h > > > > > libbpf: elf: skipping unrecognized data section(5) .rodata.str1.1 > > > > > GEN-SKEL [test_progs-no_alu32] bpf_cubic.skel.h > > > > > GEN-SKEL [test_progs-no_alu32] bpf_dctcp.skel.h > > > > > GEN-SKEL [test_progs-no_alu32] bpf_flow.skel.h > > > > > libbpf: failed to find BTF for extern 'tcp_cong_avoid_ai' [27] section: -2 > > > > > Error: failed to open BPF object file: No such file or directory > > > > > > > > The doc update is on its way: > > > > https://patchwork.kernel.org/project/netdevbpf/patch/20210330054156.2933804-1-kafai@fb.com/ > > > > > > We just updated our clang to 13, and I still get the same error above. > > Please check if the llvm/clang has this diff > > https://reviews.llvm.org/D93563
On Mon, Mar 29, 2021 at 12:11 PM Martin KaFai Lau <kafai@fb.com> wrote: > > On Mon, Mar 29, 2021 at 05:06:26PM +0100, Lorenz Bauer wrote: > > On Mon, 29 Mar 2021 at 02:25, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > > > > > > # pahole --version > > > > > > v1.17 > > > > > > > > > > That is the most likely reason. > > > > > In lib/Kconfig.debug > > > > > we have pahole >= 1.19 requirement for BTF in modules. > > > > > Though your config has CUBIC=y I suspect something odd goes on. > > > > > Could you please try the latest pahole 1.20 ? > > > > > > > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. > > > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > > > is not set? > > > > I hit the same problem on newer pahole: > > > > $ pahole --version > > v1.20 > > > > CONFIG_DYNAMIC_FTRACE=y resolves the issue. > Thanks for checking. > > pahole only generates the btf_id for external function > and ftrace-able function. Some functions in the bpf_tcp_ca_kfunc_ids list > are static (e.g. cubictcp_init), so it fails during resolve_btfids. > > I will post a patch to limit the bpf_tcp_ca_kfunc_ids list > to CONFIG_DYNAMIC_FTRACE. I will address the pahole > generation in a followup and then remove this > CONFIG_DYNAMIC_FTRACE limitation. We should still probably add CONFIG_DYNAMIC_FTRACE=y to selftests/bpf/config?
On Tue, Mar 30, 2021 at 11:44:39PM -0700, Andrii Nakryiko wrote: > On Mon, Mar 29, 2021 at 12:11 PM Martin KaFai Lau <kafai@fb.com> wrote: > > > > On Mon, Mar 29, 2021 at 05:06:26PM +0100, Lorenz Bauer wrote: > > > On Mon, 29 Mar 2021 at 02:25, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > > > > > > > > > # pahole --version > > > > > > > v1.17 > > > > > > > > > > > > That is the most likely reason. > > > > > > In lib/Kconfig.debug > > > > > > we have pahole >= 1.19 requirement for BTF in modules. > > > > > > Though your config has CUBIC=y I suspect something odd goes on. > > > > > > Could you please try the latest pahole 1.20 ? > > > > > > > > > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. > > > > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > > > > is not set? > > > > > > I hit the same problem on newer pahole: > > > > > > $ pahole --version > > > v1.20 > > > > > > CONFIG_DYNAMIC_FTRACE=y resolves the issue. > > Thanks for checking. > > > > pahole only generates the btf_id for external function > > and ftrace-able function. Some functions in the bpf_tcp_ca_kfunc_ids list > > are static (e.g. cubictcp_init), so it fails during resolve_btfids. > > > > I will post a patch to limit the bpf_tcp_ca_kfunc_ids list > > to CONFIG_DYNAMIC_FTRACE. I will address the pahole > > generation in a followup and then remove this > > CONFIG_DYNAMIC_FTRACE limitation. > > We should still probably add CONFIG_DYNAMIC_FTRACE=y to selftests/bpf/config? I thought the tracing tests have been requiring this already. Together with the new kfunc call, it may be good to make it explicit in selftests/bpf/config. I can post a diff.
On Thu, Apr 1, 2021 at 12:51 PM Martin KaFai Lau <kafai@fb.com> wrote: > > On Tue, Mar 30, 2021 at 11:44:39PM -0700, Andrii Nakryiko wrote: > > On Mon, Mar 29, 2021 at 12:11 PM Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > On Mon, Mar 29, 2021 at 05:06:26PM +0100, Lorenz Bauer wrote: > > > > On Mon, 29 Mar 2021 at 02:25, Martin KaFai Lau <kafai@fb.com> wrote: > > > > > > > > > > > > > > > > > > > > > # pahole --version > > > > > > > > v1.17 > > > > > > > > > > > > > > That is the most likely reason. > > > > > > > In lib/Kconfig.debug > > > > > > > we have pahole >= 1.19 requirement for BTF in modules. > > > > > > > Though your config has CUBIC=y I suspect something odd goes on. > > > > > > > Could you please try the latest pahole 1.20 ? > > > > > > > > > > > > Sure, I will give it a try tomorrow, I am not in control of the CI I ran. > > > > > Could you also check the CONFIG_DYNAMIC_FTRACE and also try 'y' if it > > > > > is not set? > > > > > > > > I hit the same problem on newer pahole: > > > > > > > > $ pahole --version > > > > v1.20 > > > > > > > > CONFIG_DYNAMIC_FTRACE=y resolves the issue. > > > Thanks for checking. > > > > > > pahole only generates the btf_id for external function > > > and ftrace-able function. Some functions in the bpf_tcp_ca_kfunc_ids list > > > are static (e.g. cubictcp_init), so it fails during resolve_btfids. > > > > > > I will post a patch to limit the bpf_tcp_ca_kfunc_ids list > > > to CONFIG_DYNAMIC_FTRACE. I will address the pahole > > > generation in a followup and then remove this > > > CONFIG_DYNAMIC_FTRACE limitation. > > > > We should still probably add CONFIG_DYNAMIC_FTRACE=y to selftests/bpf/config? > I thought the tracing tests have been requiring this already. Together with Yeah, I didn't mean that your feature suddenly requires that, it was always a requirement before, but we always forget to add it to config and then some users are periodically tripped up by this. > the new kfunc call, it may be good to make it explicit in selftests/bpf/config. > I can post a diff.