From: Eduard Zingerman <eddyz87@gmail.com>
To: Alan Maguire <alan.maguire@oracle.com>,
ast@kernel.org, andrii@kernel.org
Cc: daniel@iogearbox.net, jolsa@kernel.org, ihor.solodrai@linux.dev,
yonghong.song@linux.dev, song@kernel.org, qmo@kernel.org,
martin.lau@linux.dev, memxor@gmail.com, emil@etsalapatis.com,
mcgrof@kernel.org, petr.pavlu@suse.com, tj@kernel.org,
kees@kernel.org, bpf@vger.kernel.org, nathan@kernel.org,
nsc@kernel.org, arnd@arndb.de, puranjay@kernel.org,
yatsenko@meta.com, atenart@kernel.org, ojeda@kernel.org,
linux-modules@vger.kernel.org
Subject: Re: [PATCH v2 bpf-next 02/18] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC]
Date: Wed, 09 Sep 2026 15:26:58 -0700 [thread overview]
Message-ID: <e517c80062551871fa9008a223bc0044217354cb.camel@gmail.com> (raw)
In-Reply-To: <20260901165757.801449-3-alan.maguire@oracle.com>
On Tue, 2026-09-01 at 17:57 +0100, Alan Maguire wrote:
> Add support for new kinds to libbpf. BTF_KIND_LOC_PARAM and
> BTF_KIND_LOC_PROTO are dedup-able so add support for their
> deduplication, whereas since BTF_KIND_LOCSEC contains a unique
> offset it is not. LOC_PARAM is considered a primary type
> since it contains no external references; LOC_PROTO is a
> reference type consisting of LOC_PARAM references so they
> are handled in the primary and reference dedup phases
> respectively.
>
> For BTF field iteration, BTF_KIND_LOCSEC needs 2 m_offs[] values
> for the associated KIND_FUNC and KIND_LOC_PROTO type ids in
> each LOCSEC entry.
>
> Add APIs to add location param, location prototypes and location
> sections and btf_is_* tests, data accessors for each.
>
> For BTF distillation we add location info to split BTF.
>
> Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
> ---
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
(Please see a few nits below)
...
> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
...
> @@ -4395,6 +4653,45 @@ static bool btf_compat_enum(struct btf_type *t1, struct btf_type *t2)
...
> +static long btf_hash_loc_param(struct btf_type *t)
> +{
> + long h = btf_hash_common(t);
> + __u32 *v = (__u32 *)btf_loc_param(t);
> + int i, vlen = btf_vlen(t);
> +
> + for (i = 0; i <= vlen; i++, v++)
> + h = hash_combine(h, *v);
> + return h;
> +}
should v->flags be hashed as well?
> +static bool btf_equal_loc_param(struct btf_type *t1, struct btf_type *t2)
> +{
> + struct btf_loc_param *p1 = btf_loc_param(t1);
> + struct btf_loc_param *p2 = btf_loc_param(t2);
> + __u32 *v1 = (__u32 *)(p1 + 1);
> + __u32 *v2 = (__u32 *)(p2 + 1);
> + int i, vlen = btf_vlen(t1);
> +
llm is right, the p{1,2}->flags comparison is missing.
> + if (!btf_equal_common(t1, t2))
> + return false;
> + for (i = 0; i < vlen; i++, v1++, v2++) {
> + if (*v1 != *v2)
> + return false;
> + }
> + return true;
> +}
> +
> /*
> * Calculate type signature hash of STRUCT/UNION, ignoring referenced type IDs,
> * as referenced type IDs equivalence is established separately during type
> @@ -4622,6 +4919,12 @@ static int btf_dedup_prep(struct btf_dedup *d)
> case BTF_KIND_FUNC_PROTO:
> h = btf_hash_fnproto(t);
> break;
> + case BTF_KIND_LOC_PARAM:
> + h = btf_hash_loc_param(t);
> + break;
> + case BTF_KIND_LOC_PROTO:
> + h = btf_hash_loc_proto(t);
> + break;
Maybe add LOCSEC as an empty case, same as for VAR and DATASEC above?
Otherwise if someone ever tries to dedup a non-module BTF with a LOCSEC
the operation would return -EINVAL.
> default:
> pr_debug("unknown kind %d for type [%d]\n", btf_kind(t), type_id);
> return -EINVAL;
...
> @@ -5489,6 +5813,41 @@ static int btf_dedup_ref_type(struct btf_dedup *d, __u32 type_id)
> break;
> }
>
> + case BTF_KIND_LOC_PROTO: {
> + __u32 *p1, *p2;
> + __u32 i, vlen;
> +
> + p1 = btf_loc_proto_params(t);
> + vlen = btf_vlen(t);
> +
> + for (i = 0; i < vlen; i++, p1++) {
> + ref_type_id = btf_dedup_ref_type(d, *p1);
> + if (ref_type_id < 0)
> + return ref_type_id;
> + *p1 = ref_type_id;
> + }
> +
> + h = btf_hash_loc_proto(t);
> + for_each_dedup_cand(d, hash_entry, h) {
> + cand_id = hash_entry->value;
> + cand = btf_type_by_id(d->btf, cand_id);
> + if (!btf_equal_common(t, cand))
> + continue;
> + vlen = btf_vlen(cand);
Nit: btf_equal_common() checks vlen for equivalence,
so it appears that the above line is redundant.
> + p1 = btf_loc_proto_params(t);
> + p2 = btf_loc_proto_params(cand);
> + if (vlen == 0) {
> + new_id = cand_id;
> + break;
> + }
Nit: It appears that special case for `vlen == 0` is not necessary,
wouldn't memcmp(..., 0) be 0?
> + if (memcmp(p1, p2, vlen * sizeof(__u32)) == 0) {
> + new_id = cand_id;
> + break;
> + }
> + }
> + break;
> + }
> +
> default:
> return -EINVAL;
> }
...
> --- a/tools/lib/bpf/btf_iter.c
> +++ b/tools/lib/bpf/btf_iter.c
...
> @@ -94,6 +109,8 @@ int btf_field_iter_init(struct btf_field_iter *it, struct btf_type *t,
> case BTF_KIND_DECL_TAG:
> case BTF_KIND_TYPE_TAG:
> case BTF_KIND_DATASEC:
> + case BTF_KIND_LOC_PARAM:
> + case BTF_KIND_LOC_PROTO:
> it->desc = (struct btf_field_desc) {
> 1, {offsetof(struct btf_type, name_off)}
> };
> @@ -127,6 +144,11 @@ int btf_field_iter_init(struct btf_field_iter *it, struct btf_type *t,
> 1, {offsetof(struct btf_param, name_off)}
> };
> break;
> + case BTF_KIND_LOCSEC:
> + it->desc = (struct btf_field_desc) {
> + 1, {offsetof(struct btf_type, name_off)}
> + };
> + break;
Nit: can this be grouped wit the _PARAM and _PROTO cases?
...
next prev parent reply other threads:[~2026-09-09 22:27 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 16:57 [PATCH v2 bpf-next 00/18] Support inline functions in BTF Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 01/18] btf: Extend UAPI to support BTF location (inline site) info Alan Maguire
2026-09-01 17:17 ` sashiko-bot
2026-09-14 17:26 ` Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-09 22:26 ` Eduard Zingerman
2026-09-14 15:38 ` Alan Maguire
2026-09-11 19:26 ` Jiri Olsa
2026-09-14 14:29 ` Alan Maguire
2026-09-15 8:13 ` Jiri Olsa
2026-09-01 16:57 ` [PATCH v2 bpf-next 02/18] libbpf: Add support for BTF kinds LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:11 ` sashiko-bot
2026-09-09 22:26 ` Eduard Zingerman [this message]
2026-09-01 16:57 ` [PATCH v2 bpf-next 03/18] libbpf: Support moving permuted BTF types into split BTF Alan Maguire
2026-09-01 17:15 ` sashiko-bot
2026-09-01 18:14 ` bot+bpf-ci
2026-09-10 9:37 ` Eduard Zingerman
2026-09-16 7:33 ` Alan Maguire
2026-09-16 7:45 ` Eduard Zingerman
2026-09-01 16:57 ` [PATCH v2 bpf-next 04/18] selftests/bpf: Test helper support for BTF_KIND_LOC[_PARAM|_PROTO|SEC] Alan Maguire
2026-09-01 17:06 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 05/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to field iter tests Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 06/18] selftests/bpf: Add LOC_PARAM, LOC_PROTO, LOCSEC to dedup split tests Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 07/18] selftests/bpf: BTF distill tests to ensure LOC[_PARAM|_PROTO] add to split BTF Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 08/18] selftests/bpf: Validate that btf__permute transfer works Alan Maguire
2026-09-01 17:16 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 09/18] bpftool: Handle multi-split BTF by supporting multiple base BTFs Alan Maguire
2026-09-01 17:13 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 10/18] bpftool: Document support for multi-split BTF Alan Maguire
2026-09-01 17:12 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 11/18] bpftool: Add ability to dump LOC_PARAM, LOC_PROTO and LOCSEC Alan Maguire
2026-09-01 17:16 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-07 19:30 ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 12/18] resolve_btfids: Extract inline BTF Alan Maguire
2026-09-01 17:23 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 13/18] kbuild: Add support for BTF inline information Alan Maguire
2026-09-01 17:55 ` bot+bpf-ci
2026-09-14 7:50 ` Nicolas Schier
2026-09-16 7:42 ` Alan Maguire
2026-09-01 16:57 ` [PATCH v2 bpf-next 14/18] btf: Make vmlinux, module inline info available in /sys/kernel/btf Alan Maguire
2026-09-07 19:34 ` Alexei Starovoitov
2026-09-07 19:50 ` Alan Maguire
2026-09-07 20:00 ` Alexei Starovoitov
2026-09-01 16:57 ` [PATCH v2 bpf-next 15/18] btf: Support CONFIG_DEBUG_INFO_BTF_INLINE=m Alan Maguire
2026-09-01 17:24 ` sashiko-bot
2026-09-01 16:57 ` [PATCH v2 bpf-next 16/18] btf: Relocate inline BTF for modules with distilled base BTF Alan Maguire
2026-09-01 17:29 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 17/18] selftests/bpf: Test BTF sysfs inline representations Alan Maguire
2026-09-01 17:22 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
2026-09-01 16:57 ` [PATCH v2 bpf-next 18/18] selftests/bpf: Add a test verifying inline information Alan Maguire
2026-09-01 17:28 ` sashiko-bot
2026-09-01 17:55 ` bot+bpf-ci
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=e517c80062551871fa9008a223bc0044217354cb.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=atenart@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=emil@etsalapatis.com \
--cc=ihor.solodrai@linux.dev \
--cc=jolsa@kernel.org \
--cc=kees@kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mcgrof@kernel.org \
--cc=memxor@gmail.com \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=puranjay@kernel.org \
--cc=qmo@kernel.org \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=yatsenko@meta.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 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.