On Thu, 2025-02-06 at 13:15 +0800, Tao Chen wrote:
[...]
> LIBBPF_API int libbpf_probe_bpf_helper(enum bpf_prog_type prog_type,
> enum bpf_func_id helper_id, const void *opts);
> -
> +/**
> + * @brief **libbpf_probe_bpf_kfunc()** detects if host kernel supports the
> + * use of a given BPF kfunc from specified BPF program type.
> + * @param prog_type BPF program type used to check the support of BPF kfunc
> + * @param kfunc_id The btf ID of BPF kfunc to check support for
> + * @param btf_fd The module BTF FD, if kfunc is defined in kernel module,
> + * btf_fd is used to point to module's BTF, 0 means kfunc defined in vmlinux.
Regarding '0' as special value:
in general FD is considered invalid only if it's negative, 0 is a valid FD.
Andrii, I remember there was a lengthy discussion about FD==0 and BPF,
but I don't remember the conclusion.
> + * @param opts reserved for future extensibility, should be NULL
> + * @return 1, if given combination of program type and kfunc is supported; 0,
> + * if the combination is not supported; negative error code if feature
> + * detection for provided input arguments failed or can't be performed
> + *
> + * Make sure the process has required set of CAP_* permissions (or runs as
> + * root) when performing feature checking.
> + */
> +LIBBPF_API int libbpf_probe_bpf_kfunc(enum bpf_prog_type prog_type,
> + int kfunc_id, int btf_fd, const void *opts);
> /**
> * @brief **libbpf_num_possible_cpus()** is a helper function to get the
> * number of possible CPUs that the host kernel supports and expects.
> diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map
> index a8b2936a1646..e93fae101efd 100644
> --- a/tools/lib/bpf/libbpf.map
> +++ b/tools/lib/bpf/libbpf.map
> @@ -436,4 +436,5 @@ LIBBPF_1.6.0 {
> bpf_linker__add_buf;
> bpf_linker__add_fd;
> bpf_linker__new_fd;
> + libbpf_probe_bpf_kfunc;
This is now in conflict with bpf-next.
> } LIBBPF_1.5.0;
> diff --git a/tools/lib/bpf/libbpf_probes.c b/tools/lib/bpf/libbpf_probes.c
> index e142130cb83c..c7f2b2dfbcf1 100644
> --- a/tools/lib/bpf/libbpf_probes.c
> +++ b/tools/lib/bpf/libbpf_probes.c
> @@ -433,6 +433,61 @@ static bool can_probe_prog_type(enum bpf_prog_type prog_type)
> return true;
> }
>
> +int libbpf_probe_bpf_kfunc(enum bpf_prog_type prog_type, int kfunc_id, int btf_fd,
> + const void *opts)
> +{
> + struct bpf_insn insns[] = {
> + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, BPF_PSEUDO_KFUNC_CALL, btf_fd, kfunc_id),
> + BPF_EXIT_INSN(),
> + };
> + const size_t insn_cnt = ARRAY_SIZE(insns);
> + char buf[4096];
> + int *fd_array = NULL;
> + size_t fd_array_cnt = 0, fd_array_cap = fd_array_cnt;
> + int ret;
> +
> + if (opts)
> + return libbpf_err(-EINVAL);
> +
> + if (!can_probe_prog_type(prog_type))
> + return -EOPNOTSUPP;
> +
> + if (btf_fd) {
> + ret = libbpf_ensure_mem((void **)&fd_array, &fd_array_cap,
> + sizeof(int), fd_array_cnt + btf_fd);
Please take a look at the tools/testing/selftests/bpf/prog_tests/fd_array.c,
e.g. test case check_fd_array_cnt__fd_array_ok(). The offset field of the
call instruction does not have to be an fd (as it only has 16 bits),
instead it's an offset inside the fd_array.
Here it would be sufficient to allocate a small array on stack.
> + if (ret)
> + return ret;
> +
> + /* In kernel, obtain the btf fd by means of the offset of
> + * the fd_array, and the offset is the btf fd.
> + */
> + fd_array[btf_fd] = btf_fd;
> + }
[...]
