From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: <sashiko-reviews@lists.linux.dev>,
"Emil Tsalapatis" <emil@etsalapatis.com>
Cc: <bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments
Date: Mon, 01 Jun 2026 01:12:32 -0400 [thread overview]
Message-ID: <DIXGEH7ZJMH5.1QKUUBCNKPVID@etsalapatis.com> (raw)
In-Reply-To: <20260530005922.90CEE1F00893@smtp.kernel.org>
On Fri May 29, 2026 at 8:59 PM EDT, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] btf_scan_type_tags incorrectly rejects valid BPF programs containing unrecognized type tags (e.g., __user, __rcu) by returning -EOPNOTSUPP.
> - [High] btf_scan_type_tags fails to discover valid type tags if they are separated from the pointer by other BTF modifiers (like CONST, VOLATILE, or TYPEDEF).
> --
>
> commit c938604636d812339744a9ba91c4659c3d79392c
> Author: Emil Tsalapatis <emil@etsalapatis.com>
>
> verifier: parse BTF type tags for function arguments
>
> This patch extracts BTF decl tag parsing into a new function and
> introduces type tag parsing for function arguments, specifically
> looking for the arena type tag on pointers.
>
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index 17d4ab0a82068..c6a930aca67ec 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>
> [ ... ]
>
>> +static int btf_scan_type_tags(struct bpf_verifier_env *env,
>> + const struct btf *btf, u32 type_id,
>> + u32 *tags)
>> +{
>> + const struct btf_type *t;
>> +
>> + /* Find the first pointer type in the chain. */
>> + t = btf_type_skip_modifiers(btf, type_id, NULL);
>> + if (!t || !btf_type_is_ptr(t))
>> + return 0;
>> +
>> + /* We got a pointer, get all associated type tags. */
>> + t = btf_type_by_id(btf, t->type);
>> + while (t && btf_type_is_type_tag(t)) {
>
> [Severity: High]
> Does this loop terminate prematurely if the type tag is preceded by other
> modifiers like CONST, VOLATILE, or TYPEDEF?
>
> If the target type of the pointer is structured as:
> PTR -> CONST -> TYPE_TAG("arena") -> INT
>
> It appears btf_type_is_type_tag(t) would evaluate to false at the CONST
> modifier, causing the loop to exit and valid arena tags to be missed
> entirely.
>
Fair point, we can make the loop continue until it finds either a base
type or a pointer type.
>> + const char *tag = __btf_name_by_offset(btf, t->name_off);
>> +
>> + if (strcmp(tag, "arena") == 0) {
>> + *tags |= ARG_TAG_ARENA;
>> + } else {
>> + bpf_log(&env->log, "function signature member has unsupported type tag '%s'\n",
>> + tag);
>> + return -EOPNOTSUPP;
>> + }
>
> [Severity: High]
> Will this unconditionally reject valid BPF programs that contain
> unrecognized type tags like __user or __rcu?
>
> Prior to this change, standard kernel type tags on pointer arguments were
> naturally skipped by the verifier. Returning -EOPNOTSUPP here for anything
> other than arena seems like it might cause a backward compatibility
> regression for existing global subprograms that accept standard tagged
> pointers.
>
Right now imo we don't want global BPF subprogs to be able to return those
variable types in the first place. We can expand this if we ever do.
>> +
>> + t = btf_type_by_id(btf, t->type);
>> + }
>> +
>> + return 0;
>> +}
next prev parent reply other threads:[~2026-06-01 5:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-30 0:22 [PATCH bpf-next v2 0/5] bpf: Minimize annotations for arena programs Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 1/5] selftests/bpf: libarena: Add "arena" BTF type tag to __arena qualifier Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 2/5] verifier: parse BTF type tags for function arguments Emil Tsalapatis
2026-05-30 0:59 ` sashiko-bot
2026-06-01 5:12 ` Emil Tsalapatis [this message]
2026-06-01 18:37 ` Eduard Zingerman
2026-06-01 19:13 ` Emil Tsalapatis
2026-06-01 19:14 ` Eduard Zingerman
2026-05-30 0:22 ` [PATCH bpf-next v2 3/5] bpf: Allow subprogs to return arena pointers Emil Tsalapatis
2026-05-30 4:54 ` sashiko-bot
2026-06-01 5:09 ` Emil Tsalapatis
2026-06-01 19:01 ` Eduard Zingerman
2026-06-02 0:06 ` Emil Tsalapatis
2026-05-30 0:22 ` [PATCH bpf-next v2 4/5] selftests/bpf: Remove __arg_arena from the codebase Emil Tsalapatis
2026-05-30 5:03 ` sashiko-bot
2026-05-31 5:18 ` Alexei Starovoitov
2026-06-01 5:03 ` Emil Tsalapatis
2026-06-01 19:06 ` Eduard Zingerman
2026-05-30 0:22 ` [PATCH bpf-next v2 5/5] selftests/bpf: libarena: Directly return arena pointers from functions Emil Tsalapatis
2026-06-01 19:07 ` 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=DIXGEH7ZJMH5.1QKUUBCNKPVID@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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