From: Vinicius Costa Gomes <vinicius.gomes@intel.com> Date: 2021-11-10 20:54:59
When CONFIG_DEBUG_INFO_BTF is enabled and CONFIG_BPF_SYSCALL is
disabled, the following compilation error can be seen:
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
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_unregister':
net/ipv4/tcp_cubic.c:545: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:545: undefined reference to `unregister_kfunc_btf_id_set'
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_register':
net/ipv4/tcp_cubic.c:539: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:539: undefined reference to `register_kfunc_btf_id_set'
BTF .btf.vmlinux.bin.o
pahole: .tmp_vmlinux.btf: No such file or directory
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1187: vmlinux] Error 1
'bpf_tcp_ca_kfunc_list', 'register_kfunc_btf_id_set()' and
'unregister_kfunc_btf_id_set()' are only defined when
CONFIG_BPF_SYSCALL is enabled.
Fix that by moving those definitions somewhere that doesn't depend on
the bpf() syscall.
Fixes: 14f267d95fe4 ("bpf: btf: Introduce helpers for dynamic BTF set registration")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
---
kernel/bpf/btf.c | 33 ---------------------------------
kernel/bpf/core.c | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 33 deletions(-)
@@ -6344,33 +6344,8 @@ const struct bpf_func_proto bpf_btf_find_by_name_kind_proto = {BTF_ID_LIST_GLOBAL_SINGLE(btf_task_struct_ids,struct,task_struct)-/* BTF ID set registration API for modules */--structkfunc_btf_id_list{-structlist_headlist;-structmutexmutex;-};-#ifdef CONFIG_DEBUG_INFO_BTF_MODULES-voidregister_kfunc_btf_id_set(structkfunc_btf_id_list*l,-structkfunc_btf_id_set*s)-{-mutex_lock(&l->mutex);-list_add(&s->list,&l->list);-mutex_unlock(&l->mutex);-}-EXPORT_SYMBOL_GPL(register_kfunc_btf_id_set);--voidunregister_kfunc_btf_id_set(structkfunc_btf_id_list*l,-structkfunc_btf_id_set*s)-{-mutex_lock(&l->mutex);-list_del_init(&s->list);-mutex_unlock(&l->mutex);-}-EXPORT_SYMBOL_GPL(unregister_kfunc_btf_id_set);-boolbpf_check_mod_kfunc_call(structkfunc_btf_id_list*klist,u32kfunc_id,structmodule*owner){
@@ -2456,6 +2456,43 @@ int __weak bpf_arch_text_poke(void *ip, enum bpf_text_poke_type t,DEFINE_STATIC_KEY_FALSE(bpf_stats_enabled_key);EXPORT_SYMBOL(bpf_stats_enabled_key);+/* BTF ID set registration API for modules */++structkfunc_btf_id_list{+structlist_headlist;+structmutexmutex;+};++#ifdef CONFIG_DEBUG_INFO_BTF_MODULES++voidregister_kfunc_btf_id_set(structkfunc_btf_id_list*l,+structkfunc_btf_id_set*s)+{+mutex_lock(&l->mutex);+list_add(&s->list,&l->list);+mutex_unlock(&l->mutex);+}+EXPORT_SYMBOL_GPL(register_kfunc_btf_id_set);++voidunregister_kfunc_btf_id_set(structkfunc_btf_id_list*l,+structkfunc_btf_id_set*s)+{+mutex_lock(&l->mutex);+list_del_init(&s->list);+mutex_unlock(&l->mutex);+}+EXPORT_SYMBOL_GPL(unregister_kfunc_btf_id_set);++#endif++#define DEFINE_KFUNC_BTF_ID_LIST(name) \+structkfunc_btf_id_listname={LIST_HEAD_INIT(name.list),\+__MUTEX_INITIALIZER(name.mutex)};\+EXPORT_SYMBOL_GPL(name)++DEFINE_KFUNC_BTF_ID_LIST(bpf_tcp_ca_kfunc_list);+DEFINE_KFUNC_BTF_ID_LIST(prog_test_kfunc_list);+/* All definitions of tracepoints related to BPF. */#define CREATE_TRACE_POINTS#include<linux/bpf_trace.h>
On Thu, Nov 11, 2021 at 02:24:18AM IST, Vinicius Costa Gomes wrote:
When CONFIG_DEBUG_INFO_BTF is enabled and CONFIG_BPF_SYSCALL is
disabled, the following compilation error can be seen:
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
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_unregister':
net/ipv4/tcp_cubic.c:545: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:545: undefined reference to `unregister_kfunc_btf_id_set'
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_register':
net/ipv4/tcp_cubic.c:539: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:539: undefined reference to `register_kfunc_btf_id_set'
BTF .btf.vmlinux.bin.o
pahole: .tmp_vmlinux.btf: No such file or directory
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1187: vmlinux] Error 1
'bpf_tcp_ca_kfunc_list', 'register_kfunc_btf_id_set()' and
'unregister_kfunc_btf_id_set()' are only defined when
CONFIG_BPF_SYSCALL is enabled.
Fix that by moving those definitions somewhere that doesn't depend on
the bpf() syscall.
Fixes: 14f267d95fe4 ("bpf: btf: Introduce helpers for dynamic BTF set registration")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
That's just my opinion however, I'll defer to BPF maintainers.
--
Kartikeya
On Wed, Nov 10, 2021 at 1:25 PM Kumar Kartikeya Dwivedi
[off-list ref] wrote:
On Thu, Nov 11, 2021 at 02:24:18AM IST, Vinicius Costa Gomes wrote:
quoted
When CONFIG_DEBUG_INFO_BTF is enabled and CONFIG_BPF_SYSCALL is
disabled, the following compilation error can be seen:
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
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_unregister':
net/ipv4/tcp_cubic.c:545: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:545: undefined reference to `unregister_kfunc_btf_id_set'
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_register':
net/ipv4/tcp_cubic.c:539: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:539: undefined reference to `register_kfunc_btf_id_set'
BTF .btf.vmlinux.bin.o
pahole: .tmp_vmlinux.btf: No such file or directory
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1187: vmlinux] Error 1
'bpf_tcp_ca_kfunc_list', 'register_kfunc_btf_id_set()' and
'unregister_kfunc_btf_id_set()' are only defined when
CONFIG_BPF_SYSCALL is enabled.
Fix that by moving those definitions somewhere that doesn't depend on
the bpf() syscall.
Fixes: 14f267d95fe4 ("bpf: btf: Introduce helpers for dynamic BTF set registration")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
Unlikely. I would just disallow such config instead of sprinkling
the code with ifdefs.
On Thu, Nov 11, 2021 at 02:24:18AM IST, Vinicius Costa Gomes wrote:
quoted
When CONFIG_DEBUG_INFO_BTF is enabled and CONFIG_BPF_SYSCALL is
disabled, the following compilation error can be seen:
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
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_unregister':
net/ipv4/tcp_cubic.c:545: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:545: undefined reference to `unregister_kfunc_btf_id_set'
ld: net/ipv4/tcp_cubic.o: in function `cubictcp_register':
net/ipv4/tcp_cubic.c:539: undefined reference to `bpf_tcp_ca_kfunc_list'
ld: net/ipv4/tcp_cubic.c:539: undefined reference to `register_kfunc_btf_id_set'
BTF .btf.vmlinux.bin.o
pahole: .tmp_vmlinux.btf: No such file or directory
LD .tmp_vmlinux.kallsyms1
.btf.vmlinux.bin.o: file not recognized: file format not recognized
make: *** [Makefile:1187: vmlinux] Error 1
'bpf_tcp_ca_kfunc_list', 'register_kfunc_btf_id_set()' and
'unregister_kfunc_btf_id_set()' are only defined when
CONFIG_BPF_SYSCALL is enabled.
Fix that by moving those definitions somewhere that doesn't depend on
the bpf() syscall.
Fixes: 14f267d95fe4 ("bpf: btf: Introduce helpers for dynamic BTF set registration")
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
From my side, you are not missing anything, it was just random chance
that I had a 'x86_64_defconfig + debug + BTF' .config laying around and
the build broke with it. I don't have any real usecases for this
combination.
Cheers,
--
Vinicius
From: Vinicius Costa Gomes <vinicius.gomes@intel.com> Date: 2021-11-10 23:51:56
Alexei Starovoitov [off-list ref] writes:
quoted
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
Unlikely. I would just disallow such config instead of sprinkling
the code with ifdefs.
On Thu, Nov 11, 2021 at 05:21:53AM IST, Vinicius Costa Gomes wrote:
quoted hunk
Alexei Starovoitov [off-list ref] writes:
quoted
quoted
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
Unlikely. I would just disallow such config instead of sprinkling
the code with ifdefs.
BTW, you will need a little more than that, I suspect the compiler optimizes out
the register/unregister call so we don't see a build failure, but adding a side
effect gives me errors, so something like this should resolve the problem (since
kfunc_btf_id_list variable definition is behind CONFIG_BPF_SYSCALL).
From: Vinicius Costa Gomes <vinicius.gomes@intel.com> Date: 2021-11-11 02:04:40
Hi Kartikeya,
Kumar Kartikeya Dwivedi [off-list ref] writes:
quoted hunk
On Thu, Nov 11, 2021 at 05:21:53AM IST, Vinicius Costa Gomes wrote:
quoted
Alexei Starovoitov [off-list ref] writes:
quoted
quoted
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
Unlikely. I would just disallow such config instead of sprinkling
the code with ifdefs.
BTW, you will need a little more than that, I suspect the compiler optimizes out
the register/unregister call so we don't see a build failure, but adding a side
effect gives me errors, so something like this should resolve the problem (since
kfunc_btf_id_list variable definition is behind CONFIG_BPF_SYSCALL).
I could not reproduce the build failure here even when adding some side
effects, but I didn't try very hard.
As you are more familiar with the code, I would be glad if you could
take it from here and propose a patch.
Cheers,
--
Vinicius
On Thu, Nov 11, 2021 at 07:34:38AM IST, Vinicius Costa Gomes wrote:
Hi Kartikeya,
Kumar Kartikeya Dwivedi [off-list ref] writes:
quoted
On Thu, Nov 11, 2021 at 05:21:53AM IST, Vinicius Costa Gomes wrote:
quoted
Alexei Starovoitov [off-list ref] writes:
quoted
quoted
Thanks for the fix.
But instead of moving this to core.c, you can probably make the btf.h
declaration conditional on CONFIG_BPF_SYSCALL, since this is not useful in
isolation (only used by verifier for module kfunc support). For the case of
kfunc_btf_id_list variables, just define it as an empty struct and static
variables, since the definition is still inside btf.c. So it becomes a noop for
!CONFIG_BPF_SYSCALL.
I am also not sure whether BTF is useful without BPF support, but maybe I'm
missing some usecase.
Unlikely. I would just disallow such config instead of sprinkling
the code with ifdefs.
BTW, you will need a little more than that, I suspect the compiler optimizes out
the register/unregister call so we don't see a build failure, but adding a side
effect gives me errors, so something like this should resolve the problem (since
kfunc_btf_id_list variable definition is behind CONFIG_BPF_SYSCALL).
I could not reproduce the build failure here even when adding some side
effects, but I didn't try very hard.
As you are more familiar with the code, I would be glad if you could
take it from here and propose a patch.