From: Zhao Mengmeng <[email protected]> In scx-cid patchsets, sched_ext selftest failed to build with following error:
non_scx_kfunc_deny.bpf.c:17:6: error: conflicting types for 'scx_bpf_kick_cpu' 17 | void scx_bpf_kick_cpu(s32 cpu, u64 flags) __ksym; | ^ tools/testing/selftests/sched_ext/build/include/vmlinux.h:136300:13: note: previous declaration is here 136300 | extern void scx_bpf_kick_cpu(s32 cpu, u64 flags, const struct bpf_prog_aux *aux) __weak __ksym; | ^ non_scx_kfunc_deny.bpf.c:26:23: error: too few arguments to function call, expected 3, have 2 26 | scx_bpf_kick_cpu(0, 0); | ~~~~~~~~~~~~~~~~ ^ tools/testing/selftests/sched_ext/build/include/vmlinux.h:136300:13: note: 'scx_bpf_kick_cpu' declared here 136300 | extern void scx_bpf_kick_cpu(s32 cpu, u64 flags, const struct bpf_prog_aux *aux) __weak __ksym; The root cause is on scx core part, but we can avoid this by including common.bpf.h and remove scx_bpf_kick_cpu() to make it more robust, just like the usage in other xx.bpf.c. Link: https://lore.kernel.org/sched-ext/[email protected]/ Signed-off-by: Zhao Mengmeng <[email protected]> Tested-by: Cheng-Yang Chou <[email protected]> --- tools/testing/selftests/sched_ext/non_scx_kfunc_deny.bpf.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/tools/testing/selftests/sched_ext/non_scx_kfunc_deny.bpf.c b/tools/testing/selftests/sched_ext/non_scx_kfunc_deny.bpf.c index 9f16d39255e7..0d6fcc8e5eb6 100644 --- a/tools/testing/selftests/sched_ext/non_scx_kfunc_deny.bpf.c +++ b/tools/testing/selftests/sched_ext/non_scx_kfunc_deny.bpf.c @@ -9,12 +9,7 @@ * Copyright (C) 2026 Cheng-Yang Chou <[email protected]> */ -#include <vmlinux.h> -#include <bpf/bpf_helpers.h> -#include <bpf/bpf_tracing.h> - -/* SCX kfunc from scx_kfunc_ids_any set */ -void scx_bpf_kick_cpu(s32 cpu, u64 flags) __ksym; +#include <scx/common.bpf.h> SEC("struct_ops/ssthresh") __u32 BPF_PROG(tcp_ca_ssthresh, struct sock *sk) --- base-commit: eff158514a85c1b81966667a880dd8bcd29bbbd1 change-id: 20260423-b4-selftest-fix-d87cdda6185e Best regards, -- Zhao Mengmeng <[email protected]>
