public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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;
> +}

[...]

      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