From: Eduard Zingerman <eddyz87@gmail.com>
To: paulhoussel2@gmail.com, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
Paul Houssel <paul.houssel@orange.com>,
Martin Horth <martin.horth@telecom-sudparis.eu>,
Ouail Derghal <ouail.derghal@imt-atlantique.fr>,
Guilhem Jazeron <guilhem.jazeron@inria.fr>,
Ludovic Paillat <ludovic.paillat@inria.fr>,
Robin Theveniaut <robin.theveniaut@irit.fr>,
Tristan d'Audibert <tristan.daudibert@gmail.com>
Subject: Re: [PATCH] libbpf: fix BTF dedup to support recursive typedef definitions
Date: Mon, 10 Nov 2025 11:14:52 -0800 [thread overview]
Message-ID: <67738d278b9845c4d37bffba6a36feec1e2722f8.camel@gmail.com> (raw)
In-Reply-To: <20251107153408.159342-1-paulhoussel2@gmail.com>
On Fri, 2025-11-07 at 16:34 +0100, paulhoussel2@gmail.com wrote:
[...]
> @@ -4936,10 +4963,77 @@ static int btf_dedup_struct_types(struct btf_dedup *d)
> return 0;
> }
>
> +/*
> + * Deduplicate typedef types.
> + *
> + * Similar as for struct/union types, for each typedef type its type
> + * signature hash is calculated, taking into account type's name
> + * and its size, but ignoring type ID's referenced from fields,
> + * because they might not be deduped completely until after
> + * reference types deduplication phase.
> + */
> +static int btf_dedup_typedef_type(struct btf_dedup *d, __u32 type_id)
> +{
This function is effectively identical to btf_dedup_struct_type(),
the only things that differ are calls to hash and equal funcs:
t = btf_type_by_id(d->btf, type_id);
kind = btf_kind(t);
- if (kind != BTF_KIND_STRUCT && kind != BTF_KIND_UNION)
+ if (kind != BTF_KIND_TYPEDEF)
return 0;
-
- h = btf_hash_struct(t);
+ h = btf_hash_typedef(t);
for_each_dedup_cand(d, hash_entry, h) {
__u32 cand_id = hash_entry->value;
int eq;
cand_type = btf_type_by_id(d->btf, cand_id);
- if (!btf_shallow_equal_struct(t, cand_type))
+ if (!btf_equal_typedef(t, cand_type))
continue;
btf_dedup_clear_hypot_map(d);
I don't like coping the logic related to hypot map maintenance and
d->hypot_adjust_canon flat processing.
Instead of copy-pasting, could you please modify btf_dedup_struct_type()?
- extend the type check to allow BTF_KIND_TYPEDEF;
- replace calls to btf_hash_struct() and btf_shallow_equal_struct()
with calls to functions that select btf_hash_struct() /
btf_hash_typedef() etc basing on the type?
Also, could you please add tests?
See tools/testing/selftests/bpf/prog_tests/btf.c.
> + struct btf_type *cand_type, *t;
> + struct hashmap_entry *hash_entry;
> + /* if we don't find equivalent type, then we are canonical */
> + __u32 new_id = type_id;
> + __u16 kind;
> + long h;
> +
> + if (d->map[type_id] <= BTF_MAX_NR_TYPES)
> + return 0;
> +
> + t = btf_type_by_id(d->btf, type_id);
> + kind = btf_kind(t);
> +
> + if (kind != BTF_KIND_TYPEDEF)
> + return 0;
> + h = btf_hash_typedef(t);
> + for_each_dedup_cand(d, hash_entry, h) {
> + __u32 cand_id = hash_entry->value;
> + int eq;
> +
> + cand_type = btf_type_by_id(d->btf, cand_id);
> + if (!btf_equal_typedef(t, cand_type))
> + continue;
> +
> + btf_dedup_clear_hypot_map(d);
> + eq = btf_dedup_is_equiv(d, type_id, cand_id);
> + if (eq < 0)
> + return eq;
> + if (!eq)
> + continue;
> + btf_dedup_merge_hypot_map(d);
> + if (d->hypot_adjust_canon) /* not really equivalent */
> + continue;
> + new_id = cand_id;
> + break;
> + }
> +
> + d->map[type_id] = new_id;
> + if (type_id == new_id && btf_dedup_table_add(d, h, type_id))
> + return -ENOMEM;
> +
> + return 0;
> +}
[...]
prev parent reply other threads:[~2025-11-10 19:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 15:34 [PATCH] libbpf: fix BTF dedup to support recursive typedef definitions paulhoussel2
2025-11-07 19:45 ` Eduard Zingerman
2025-11-07 20:49 ` polo
2025-11-10 19:06 ` Eduard Zingerman
2025-11-10 19:14 ` Eduard Zingerman [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=67738d278b9845c4d37bffba6a36feec1e2722f8.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=guilhem.jazeron@inria.fr \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.paillat@inria.fr \
--cc=martin.horth@telecom-sudparis.eu \
--cc=martin.lau@linux.dev \
--cc=ouail.derghal@imt-atlantique.fr \
--cc=paul.houssel@orange.com \
--cc=paulhoussel2@gmail.com \
--cc=robin.theveniaut@irit.fr \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=tristan.daudibert@gmail.com \
--cc=yonghong.song@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