All of lore.kernel.org
 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: 4+ 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]

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 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.