From: Tao Chen <chen.dylane@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
eddyz87@gmail.com, haoluo@google.com, jolsa@kernel.org,
qmo@kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org,
Tao Chen <dylane.chen@didiglobal.com>
Subject: Re: [PATCH bpf-next v6 3/4] libbpf: Add libbpf_probe_bpf_kfunc API
Date: Wed, 12 Feb 2025 10:33:21 +0800 [thread overview]
Message-ID: <49282239-350a-4a76-9243-501373009bec@gmail.com> (raw)
In-Reply-To: <CAEf4BzbQv4D65kuYRr+i8aqGqUY+YT7oKGJNNBxSUUBsj+Zhrw@mail.gmail.com>
在 2025/2/12 06:24, Andrii Nakryiko 写道:
> On Tue, Feb 11, 2025 at 3:19 AM Tao Chen <chen.dylane@gmail.com> wrote:
>>
>> Similarly to libbpf_probe_bpf_helper, the libbpf_probe_bpf_kfunc
>> used to test the availability of the different eBPF kfuncs on the
>> current system.
>>
>> Cc: Tao Chen <dylane.chen@didiglobal.com>
>> Signed-off-by: Tao Chen <chen.dylane@gmail.com>
>> ---
>> tools/lib/bpf/libbpf.h | 19 +++++++++++++-
>> tools/lib/bpf/libbpf.map | 1 +
>> tools/lib/bpf/libbpf_probes.c | 48 +++++++++++++++++++++++++++++++++++
>> 3 files changed, 67 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>> index 3020ee45303a..e796e38cf255 100644
>> --- a/tools/lib/bpf/libbpf.h
>> +++ b/tools/lib/bpf/libbpf.h
>> @@ -1680,7 +1680,24 @@ LIBBPF_API int libbpf_probe_bpf_map_type(enum bpf_map_type map_type, const void
>> */
>> 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, which is >= 0, and -1 means kfunc
>> + * defined in vmlinux.
>> + * @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 b5a838de6f47..3bbfe13aeb6a 100644
>> --- a/tools/lib/bpf/libbpf.map
>> +++ b/tools/lib/bpf/libbpf.map
>> @@ -438,4 +438,5 @@ LIBBPF_1.6.0 {
>> bpf_linker__new_fd;
>> btf__add_decl_attr;
>> btf__add_type_attr;
>> + libbpf_probe_bpf_kfunc;
>> } LIBBPF_1.5.0;
>> diff --git a/tools/lib/bpf/libbpf_probes.c b/tools/lib/bpf/libbpf_probes.c
>> index 8ed92ea922b3..ab5591c385de 100644
>> --- a/tools/lib/bpf/libbpf_probes.c
>> +++ b/tools/lib/bpf/libbpf_probes.c
>> @@ -431,6 +431,54 @@ 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, 1, kfunc_id),
>> + BPF_EXIT_INSN(),
>> + };
>> + const size_t insn_cnt = ARRAY_SIZE(insns);
>> + char buf[4096];
>> + int fd_array[2] = {-1};
>> + int ret;
>> +
>> + if (opts)
>> + return libbpf_err(-EINVAL);
>> +
>> + if (!can_probe_prog_type(prog_type))
>> + return -EOPNOTSUPP;
>
> libbpf_err() here
>
> pw-bot: cr
>
Ack.
>> +
>> + if (btf_fd >= 0) {
>> + fd_array[1] = btf_fd;
>> + } else if (btf_fd == -1) {
>
> let's not hard-code the equality, use < 0 (though I'd follow
> verifier's offset == 0 convention for vmlinux BTF here as well to stay
> conceptually consistent)
>
Ack.
>> + /* insn.off = 0, means vmlinux btf */
>> + insns[0].off = 0;
>> + } else {
>> + return libbpf_err(-EINVAL);
>> + }
>> +
>> + buf[0] = '\0';
>> + ret = probe_prog_load(prog_type, insns, insn_cnt, btf_fd >= 0 ? fd_array : NULL,
>> + buf, sizeof(buf));
>> + if (ret < 0)
>> + return libbpf_err(ret);
>> +
>> + /* If BPF verifier recognizes BPF kfunc but it's not supported for
>> + * given BPF program type, it will emit "calling kernel function
>> + * bpf_cpumask_create is not allowed", if the kfunc id is invalid,
>
> bpf_cpumask_create -> <name> to keep comments generic?
>
>> + * it will emit "kernel btf_id 4294967295 is not a function". If btf fd
>
> same as above, use <id> placeholder instead of specific number?
>
> and keep BTF (all caps) use consistent, please
Ack.
>
>> + * invalid in module btf, it will emit "invalid module BTF fd specified" or
>
> ditto, btf -> BTF
>
>> + * "negative offset disallowed for kernel module function call"
>> + */
>> + if (ret == 0 && (strstr(buf, "not allowed") || strstr(buf, "not a function") ||
>> + (strstr(buf, "invalid module BTF fd")) ||
>> + (strstr(buf, "negative offset disallowed"))))
>
> stylistically, given amount of checks, I'd probably go with the
> following structure
Ack. will change it.
>
> if (ret > 0)
> return 1;
>
> if (strstr(buf, "not allowed") ||
> strstr(buf, "not a function") ||
> ...)
> return 0;
>
>> + return 0;
>> +
>> + return 1; /* assume supported */
>> +}
>> +
>> int libbpf_probe_bpf_helper(enum bpf_prog_type prog_type, enum bpf_func_id helper_id,
>> const void *opts)
>> {
>> --
>> 2.43.0
>>
--
Best Regards
Dylane Chen
next prev parent reply other threads:[~2025-02-12 2:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-11 11:18 [PATCH bpf-next v6 0/4] Add prog_kfunc feature probe Tao Chen
2025-02-11 11:18 ` [PATCH bpf-next v6 1/4] libbpf: Extract prog load type check from libbpf_probe_bpf_helper Tao Chen
2025-02-11 11:18 ` [PATCH bpf-next v6 2/4] libbpf: Init fd_array when prog probe load Tao Chen
2025-02-11 11:18 ` [PATCH bpf-next v6 3/4] libbpf: Add libbpf_probe_bpf_kfunc API Tao Chen
2025-02-11 14:36 ` Jiri Olsa
2025-02-11 16:09 ` Tao Chen
2025-02-11 22:24 ` Andrii Nakryiko
2025-02-12 2:33 ` Tao Chen [this message]
2025-02-11 11:18 ` [PATCH bpf-next v6 4/4] selftests/bpf: Add libbpf_probe_bpf_kfunc API selftests Tao Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49282239-350a-4a76-9243-501373009bec@gmail.com \
--to=chen.dylane@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dylane.chen@didiglobal.com \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=qmo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.