BPF List
 help / color / mirror / Atom feed
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


  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