BPF List
 help / color / mirror / Atom feed
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;
> +}
> +

[...]


  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