From: Eduard Zingerman <eddyz87@gmail.com>
To: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
martin.lau@kernel.org
Cc: kernel-team@meta.com
Subject: Re: [PATCH v2 bpf-next 06/10] bpf: support 'arg:xxx' btf_decl_tag-based hints for global subprog args
Date: Wed, 13 Dec 2023 19:43:17 +0200 [thread overview]
Message-ID: <bb0885d8a86c2b03be918ef506466e6a2f90f294.camel@gmail.com> (raw)
In-Reply-To: <20231212232535.1875938-7-andrii@kernel.org>
On Tue, 2023-12-12 at 15:25 -0800, Andrii Nakryiko wrote:
> Add support for annotating global BPF subprog arguments to provide more
> information about expected semantics of the argument. Currently,
> verifier relies purely on argument's BTF type information, and supports
> three general use cases: scalar, pointer-to-context, and
> pointer-to-fixed-size-memory.
>
> Scalar and pointer-to-fixed-mem work well in practice and are quite
> natural to use. But pointer-to-context is a bit problematic, as typical
> BPF users don't realize that they need to use a special type name to
> signal to verifier that argument is not just some pointer, but actually
> a PTR_TO_CTX. Further, even if users do know which type to use, it is
> limiting in situations where the same BPF program logic is used across
> few different program types. Common case is kprobes, tracepoints, and
> perf_event programs having a helper to send some data over BPF perf
> buffer. bpf_perf_event_output() requires `ctx` argument, and so it's
> quite cumbersome to share such global subprog across few BPF programs of
> different types, necessitating extra static subprog that is context
> type-agnostic.
>
> Long story short, there is a need to go beyond types and allow users to
> add hints to global subprog arguments to define expectations.
>
> This patch adds such support for two initial special tags:
> - pointer to context;
> - non-null qualifier for generic pointer arguments.
>
> All of the above came up in practice already and seem generally useful
> additions. Non-null qualifier is an often requested feature, which
> currently has to be worked around by having unnecessary NULL checks
> inside subprogs even if we know that arguments are never NULL. Pointer
> to context was discussed earlier.
>
> As for implementation, we utilize btf_decl_tag attribute and set up an
> "arg:xxx" convention to specify argument hint. As such:
> - btf_decl_tag("arg:ctx") is a PTR_TO_CTX hint;
> - btf_decl_tag("arg:nonnull") marks pointer argument as not allowed to
> be NULL, making NULL check inside global subprog unnecessary.
>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
[...]
> @@ -6846,7 +6846,35 @@ int btf_prepare_func_args(struct bpf_verifier_env *env, int subprog)
> * Only PTR_TO_CTX and SCALAR are supported atm.
> */
> for (i = 0; i < nargs; i++) {
> + bool is_nonnull = false;
> + const char *tag;
> +
> t = btf_type_by_id(btf, args[i].type);
> +
> + tag = btf_find_decl_tag_value(btf, fn_t, i, "arg:");
> + if (IS_ERR(tag) && PTR_ERR(tag) == -ENOENT) {
> + tag = NULL;
> + } else if (IS_ERR(tag)) {
> + bpf_log(log, "arg#%d type's tag fetching failure: %ld\n", i, PTR_ERR(tag));
> + return PTR_ERR(tag);
> + }
> + /* 'arg:<tag>' decl_tag takes precedence over derivation of
> + * register type from BTF type itself
> + */
> + if (tag) {
> + /* disallow arg tags in static subprogs */
> + if (!is_global) {
> + bpf_log(log, "arg#%d type tag is not supported in static functions\n", i);
> + return -EOPNOTSUPP;
> + }
> + if (strcmp(tag, "ctx") == 0) {
> + sub->args[i].arg_type = ARG_PTR_TO_CTX;
> + continue;
Nit: personally, I'd keep tags parsing and processing logically separate:
- at this point set a flag 'is_ctx'
- and modify the check below as follows:
if (is_ctx || (btf_type_is_ptr(t) && btf_get_prog_ctx_type(log, btf, t, prog_type, i))) {
sub->args[i].arg_type = ARG_PTR_TO_CTX;
continue;
}
So that there is only one place where ARG_PTR_TO_CTX is assigned.
Feel free to ignore.
[...]
next prev parent reply other threads:[~2023-12-13 17:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-12 23:25 [PATCH v2 bpf-next 00/10] Enhance BPF global subprogs with argument tags Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 01/10] bpf: abstract away global subprog arg preparation logic from reg state setup Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 02/10] bpf: reuse btf_prepare_func_args() check for main program BTF validation Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-13 18:06 ` Andrii Nakryiko
2023-12-13 18:14 ` Eduard Zingerman
2023-12-13 18:23 ` Andrii Nakryiko
2023-12-13 18:29 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 03/10] bpf: prepare btf_prepare_func_args() for handling static subprogs Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 04/10] bpf: move subprog call logic back to verifier.c Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 05/10] bpf: reuse subprog argument parsing logic for subprog call checks Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 06/10] bpf: support 'arg:xxx' btf_decl_tag-based hints for global subprog args Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman [this message]
2023-12-13 19:18 ` Andrii Nakryiko
2023-12-13 19:33 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 07/10] bpf: add support for passing dynptr pointer to global subprog Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 08/10] libbpf: add __arg_xxx macros for annotating global func args Andrii Nakryiko
2023-12-13 17:43 ` Eduard Zingerman
2023-12-12 23:25 ` [PATCH v2 bpf-next 09/10] selftests/bpf: add global subprog annotation tests Andrii Nakryiko
2023-12-12 23:25 ` [PATCH v2 bpf-next 10/10] selftests/bpf: add freplace of BTF-unreliable main prog test Andrii Nakryiko
2023-12-13 17:44 ` Eduard Zingerman
2023-12-13 19:25 ` Andrii Nakryiko
2023-12-13 20:39 ` Eduard Zingerman
2023-12-13 22:48 ` Andrii Nakryiko
2023-12-14 0:14 ` Eduard Zingerman
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=bb0885d8a86c2b03be918ef506466e6a2f90f294.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@meta.com \
--cc=martin.lau@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox