From: Ihor Solodrai <ihor.solodrai@linux.dev>
To: Jiri Olsa <olsajiri@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Alan Maguire <alan.maguire@oracle.com>,
Emil Tsalapatis <emil@etsalapatis.com>,
bpf@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 4/4] selftests/bpf: Add kfunc set test to resolve_btfids
Date: Tue, 23 Jun 2026 17:59:13 -0700 [thread overview]
Message-ID: <16f991c7-eb45-48a2-b1d6-fe01ba6ff454@linux.dev> (raw)
In-Reply-To: <ajPlJ81PL_YaHsBo@krava>
On 6/18/26 5:31 AM, Jiri Olsa wrote:
> On Wed, Jun 17, 2026 at 02:06:19PM -0700, Ihor Solodrai wrote:
>> Extend the resolve_btfids selftest to cover kfunc sets defined with
>> BTF_KFUNCS_START/BTF_KFUNCS_END.
>>
>> The test verifies that resolve_btfids correctly processes BTF_ID_FLAGS,
>> resolves function IDs, and checks the kfunc set is sorted.
>>
>> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
>> Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
>> ---
>> .../selftests/bpf/prog_tests/resolve_btfids.c | 63 ++++++++++++++++---
>> tools/testing/selftests/bpf/progs/btf_data.c | 10 +++
>> 2 files changed, 66 insertions(+), 7 deletions(-)
>>
>> diff --git a/tools/testing/selftests/bpf/prog_tests/resolve_btfids.c b/tools/testing/selftests/bpf/prog_tests/resolve_btfids.c
>> index 6bcadee50bb8..65ede3ac5845 100644
>> --- a/tools/testing/selftests/bpf/prog_tests/resolve_btfids.c
>> +++ b/tools/testing/selftests/bpf/prog_tests/resolve_btfids.c
>> @@ -12,6 +12,10 @@
>>
>> #define BTF_DATA_FILE "resolve_btfids.test.o.BTF"
>>
>> +#ifndef KF_FASTCALL
>> +#define KF_FASTCALL (1 << 12)
>> +#endif
>> +
>> struct symbol {
>> const char *name;
>> int type;
>> @@ -28,6 +32,17 @@ struct symbol test_symbols[] = {
>> { "func", BTF_KIND_FUNC, -1 },
>> };
>>
>> +struct kfunc_symbol {
>> + const char *name;
>> + s32 id;
>> + u32 flags;
>> +};
>> +
>> +static struct kfunc_symbol kfunc_symbols[] = {
>> + { "kfunc_a", -1, 0 },
>> + { "kfunc_b", -1, KF_FASTCALL },
>> +};
>> +
>> /* Align the .BTF_ids section to 4 bytes */
>> asm (
>> ".pushsection " BTF_IDS_SECTION " ,\"a\"; \n"
>> @@ -35,9 +50,9 @@ asm (
>> ".popsection; \n");
>>
>> /*
>> - * test_list_local and test_set are .local symbols placed in .BTF_ids by
>> - * inline asm, and are read here directly by C name. To the compiler they
>> - * are plain, default-visibility extern objects.
>> + * test_list_local, test_set and test_kfunc_set are .local symbols placed
>> + * in .BTF_ids by inline asm, and are read here directly by C name. To the
>> + * compiler they are plain, default-visibility extern objects.
>> *
>> * When test_progs is linked as a position-independent executable (PIE),
>> * taking the address of such an extern is routed through the GOT. The
>> @@ -69,6 +84,11 @@ BTF_ID(struct, S)
>> BTF_ID(union, U)
>> BTF_ID(func, func)
>> BTF_SET_END(test_set)
>> +
>> +BTF_KFUNCS_START(test_kfunc_set)
>> +BTF_ID_FLAGS(func, kfunc_a)
>> +BTF_ID_FLAGS(func, kfunc_b, KF_FASTCALL)
>> +BTF_KFUNCS_END(test_kfunc_set)
>> #pragma GCC visibility pop
>>
>> extern __u32 test_list_global[];
>> @@ -92,6 +112,8 @@ __resolve_symbol(struct btf *btf, int type_id)
>> if (!ASSERT_OK_PTR(type, "btf__type_by_id"))
>> return -1;
>>
>> + str = btf__name_by_offset(btf, type->name_off);
>
> should we assert str != NULL like below?
Andrii commented earlier that there is no point in double checking
strings returned by btf__name_by_offset(), we should always expect a
valid string. Crashing is fine if it's not the case.
The check below is removed.
>
> jirka
>
>> +
>> for (i = 0; i < ARRAY_SIZE(test_symbols); i++) {
>> if (test_symbols[i].id >= 0)
>> continue;
>> @@ -99,14 +121,20 @@ __resolve_symbol(struct btf *btf, int type_id)
>> if (BTF_INFO_KIND(type->info) != test_symbols[i].type)
>> continue;
>>
>> - str = btf__name_by_offset(btf, type->name_off);
>> - if (!ASSERT_OK_PTR(str, "btf__name_by_offset"))
>> - return -1;
>> -
>> if (!strcmp(str, test_symbols[i].name))
>> test_symbols[i].id = type_id;
>> }
>>
>
> SNIP
next prev parent reply other threads:[~2026-06-24 0:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 21:06 [PATCH bpf-next v1 0/4] Modernize resolve_btfids selftest Ihor Solodrai
2026-06-17 21:06 ` [PATCH bpf-next v1 1/4] tools/bpf: Sync btf_ids.h to tools Ihor Solodrai
2026-06-19 0:30 ` Eduard Zingerman
2026-06-17 21:06 ` [PATCH bpf-next v1 2/4] selftests/bpf: Modernize resolve_btfids test scaffolding Ihor Solodrai
2026-06-19 0:30 ` Eduard Zingerman
2026-06-17 21:06 ` [PATCH bpf-next v1 3/4] selftests/bpf: Fix resolve_btfids test reads of BTF ID sets in PIE builds Ihor Solodrai
2026-06-17 21:06 ` [PATCH bpf-next v1 4/4] selftests/bpf: Add kfunc set test to resolve_btfids Ihor Solodrai
2026-06-18 12:31 ` Jiri Olsa
2026-06-24 0:59 ` Ihor Solodrai [this message]
2026-06-19 1:01 ` Eduard Zingerman
2026-06-18 12:32 ` [PATCH bpf-next v1 0/4] Modernize resolve_btfids selftest Jiri Olsa
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=16f991c7-eb45-48a2-b1d6-fe01ba6ff454@linux.dev \
--to=ihor.solodrai@linux.dev \
--cc=alan.maguire@oracle.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=emil@etsalapatis.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=memxor@gmail.com \
--cc=olsajiri@gmail.com \
/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