From: Yonghong Song <yonghong.song@linux.dev>
To: Emil Tsalapatis <emil@etsalapatis.com>, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, memxor@gmail.com,
daniel@iogearbox.net, eddyz87@gmail.com,
mattbobrowski@google.com, Vineet Gupta <vineet.gupta@linux.dev>,
"Jose E. Marchesi" <jose.marchesi@oracle.com>,
David Faust <david.faust@oracle.com>
Subject: Re: [PATCH bpf-next v2] bpf: Allow type tag BTF records to succeed other modifier records
Date: Sat, 20 Jun 2026 10:53:32 -0700 [thread overview]
Message-ID: <173eddc1-22d3-4edc-8561-b4614bb13278@linux.dev> (raw)
In-Reply-To: <20260616061454.7869-1-emil@etsalapatis.com>
On 6/15/26 11:14 PM, Emil Tsalapatis wrote:
> As of recently, Clang is able to attach type tag records to modifier BTF
> records. This is useful for using typedefs that encompass a base type
Please add the following link in the commit message:
https://github.com/llvm/llvm-project/pull/203089
The above 'clang is able to attach type tag records to modifier BTF records'
is not precise. The context for this requires typedef.
> and a type tag, e.g.:
>
> typedef struct rbtree __arena rbtree_t;
>
> Modify btf_check_type_tags() so that it allows this sequence of records.
> The function now only checks for record loops in BTF modifier record
> chains. Rename to btf_check_modifier_chain_length to reflect this.
Currently, for clang, the typetag is always right after typedef, e.g.,
typedef struct rbtree __arena const rbtree_t
=> typedef -> __arena -> const -> struct rbtree
typedef const struct rbtree __arena rbtree_t
=> typedef -> __arena -> const -> struct rbtree
typedef struct rbtree const __arena rbtree_t
=> typedef -> __arena -> const -> struct rbtree
gcc has not yet implemented this (typedef struct rbtree __arena rbtree_t).
Not sure whether gcc will follow the above clang pattern or
it may generate something like
typedef -> const -> __arena -> struct rbbree
or not.
But considering gcc also follows pattern like
ptr -> __arena -> const -> struct rbtree
likely in the future they may support like
typedef -> __arena -> const -> struct rbtree
Maybe we should keep similar ordering ('ptr -> __arena' => 'typedef -> __arena')?
Jose, David, what do you think?
>
> Also expand the BTF modifier traversal code to take into account that
> type record can be interleaved with other modifier records. In effect
> this means traversing all modifiers to collect the type tags.
>
> Also modify existing selftests to now accept modifier records (const,
> typedef) that point to type tag records.
>
> Cc: Yonghong Song <yonghong.song@linux.dev>
> Cc: Vineet Gupta <vineet.gupta@linux.dev>
> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
>
> Changelog v1->v2:
>
> - Factor main type tag walk into a separate function (Eduard). The
> change makes certain code paths now more permissive (unrecognized tags
> do not cause an error for kptrs, and we can have multiple instances of
> the same tag), but imo handling those edge cases was a grey area in the
> first place and it is better to consistently scan type tags the same
> way everywhere.
>
> kernel/bpf/btf.c | 209 +++++++++++--------
> tools/testing/selftests/bpf/prog_tests/btf.c | 12 +-
> 2 files changed, 125 insertions(+), 96 deletions(-)
>
> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
> index ef4402274786..4ba2ff132503 100644
> --- a/kernel/bpf/btf.c
> +++ b/kernel/bpf/btf.c
> @@ -28,6 +28,7 @@
> #include <linux/string.h>
> #include <linux/sysfs.h>
> #include <linux/overflow.h>
> +#include <linux/bitops.h>
>
> #include <net/netfilter/nf_bpf_link.h>
>
> @@ -3472,12 +3473,69 @@ static int btf_find_struct(const struct btf *btf, const struct btf_type *t,
> return BTF_FIELD_FOUND;
> }
>
> +struct btf_type_tag_match {
> + const char *name;
> + u32 flag;
> +};
> +
> +struct btf_type_tag_walk_ctx {
> + const struct btf_type *t; /* Input/Output */
> + u32 id; /* Output */
> + u32 res; /* Output */
> +};
> +
> +static int btf_type_tag_walk(const struct btf *btf,
> + struct btf_type_tag_walk_ctx *ctx,
> + const struct btf_type_tag_match *matches,
> + u32 match_cnt)
> +{
> + const struct btf_type *t = ctx->t;
> + u32 res = 0;
> + const char *tag;
> + u32 id, i;
> +
> + do {
> + id = t->type;
> + t = btf_type_by_id(btf, id);
> +
> + if (!btf_type_is_modifier(t))
> + break;
> +
> + if (!btf_type_is_type_tag(t) || btf_type_kflag(t))
> + continue;
> +
> + tag = __btf_name_by_offset(btf, t->name_off);
> + for (i = 0; i < match_cnt; i++) {
> + if (strcmp(tag, matches[i].name))
> + continue;
> + res |= matches[i].flag;
> + break;
> + }
> + } while (true);
> +
> + /* We only support a single tag. */
> + if (hweight32(res) > 1)
> + return -EINVAL;
> +
> + ctx->t = t;
> + ctx->id = id;
> + ctx->res = res;
> +
> + return 0;
> +}
> +
[...]
next prev parent reply other threads:[~2026-06-20 17:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 6:14 [PATCH bpf-next v2] bpf: Allow type tag BTF records to succeed other modifier records Emil Tsalapatis
2026-06-16 6:42 ` bot+bpf-ci
2026-06-16 7:12 ` Emil Tsalapatis
2026-06-20 17:53 ` Yonghong Song [this message]
2026-06-22 1:10 ` patchwork-bot+netdevbpf
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=173eddc1-22d3-4edc-8561-b4614bb13278@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=david.faust@oracle.com \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jose.marchesi@oracle.com \
--cc=mattbobrowski@google.com \
--cc=memxor@gmail.com \
--cc=vineet.gupta@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