From: Yonghong Song <yonghong.song@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, andrii@kernel.org, daniel@iogearbox.net,
eddyz87@gmail.com, kernel-team@fb.com, martin.lau@kernel.org,
mason@kernel.org, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next 1/5] selftests/bpf: Test by-value __int128 kfunc arguments at an odd slot
Date: Fri, 9 Oct 2026 19:04:23 +0200 [thread overview]
Message-ID: <741a2407-5d2e-44e4-b6a4-241089693a90@linux.dev> (raw)
In-Reply-To: <18d9233ff61909ba7ef175caaa63248c2e70abfb0fe7d56a4fdb350d43eaa44c@mail.kernel.org>
On 10/9/26 9:48 AM, bot+bpf-ci@kernel.org wrote:
>> selftests/bpf: Test by-value __int128 kfunc arguments at an odd slot
> TL;DR: On arm64 with an older pahole, the two new kfuncs lack BTF, so
> bpf_testmod.ko may fail to build or load, losing all bpf_testmod selftests,
> not just the new ones.
>
>> On arm64 the first two kfuncs get BTF only with the pahole patch
>> "dwarf_loader: Skip the argument register the arm64 ABI leaves as a hole"
>> [2], in pahole master after v1.32. An older pahole finds the argument
>> after the __int128 in an unexpected register, x4 rather than x3, and
>> leaves the function out of BTF, so the tests fail to load there.
>> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
>> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
>> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> [ ... ]
>
>> @@ -1763,6 +1786,9 @@ BTF_ID_FLAGS(func, bpf_kfunc_call_test_ret_deep)
>> BTF_ID_FLAGS(func, bpf_kfunc_call_test_ret_ii)
>> BTF_ID_FLAGS(func, bpf_kfunc_call_test_pair_arg)
>> BTF_ID_FLAGS(func, bpf_kfunc_call_test_i128_arg)
>> +BTF_ID_FLAGS(func, bpf_kfunc_call_test_i128_arg_odd)
>> +BTF_ID_FLAGS(func, bpf_kfunc_call_test_i128_arg_odd_many)
>> +BTF_ID_FLAGS(func, bpf_kfunc_call_test_i128_arg_stack_hole)
>> BTF_ID_FLAGS(func, bpf_kfunc_call_test_i128_arg_pad)
> Is the failure on arm64 with an older pahole really limited to the two new
> tests?
Yes, we use the latest pahole in github. Note that latest pahole is
also available to CI.
>
> Both bpf_kfunc_call_test_i128_arg_odd and
> bpf_kfunc_call_test_i128_arg_odd_many are added to
> bpf_testmod_check_kfunc_ids, the module's main kfunc set.
>
> With no BTF FUNC for them, resolve_btfids only warns ("no BTF func for
> kfunc ..." in collect_kfuncs() and "unresolved symbol ..." in id_patch())
> and leaves their set8 ids at 0. With CONFIG_WERROR=y, scripts/Makefile.btf
> passes --fatal_warnings, so bpf_testmod.ko would fail to build.
>
> Otherwise, at module load bpf_testmod_init() calls
> register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &bpf_testmod_kfunc_set),
> and __register_btf_kfunc_id_set() checks every entry:
>
> for (i = 0; i < kset->set->cnt; i++) {
> ret = btf_check_kfunc_protos(btf, btf_relocate_id(btf, kset->set->pairs[i].id), ...);
> if (ret)
> goto err_out;
> }
>
> btf_check_kfunc_protos() does:
>
> func = btf_type_by_id(btf, func_id);
> if (!func || !btf_type_is_func(func))
> return -EINVAL;
>
> Id 0 resolves to btf_void in the base BTF (btf_relocate_id() maps 0 to 0),
> so this returns -EINVAL.
>
> That would reject the whole set, bpf_testmod_init() would return the error,
> and bpf_testmod.ko would not load. test_progs then prints "Selftests
> relying on bpf_testmod.ko will be skipped", so every bpf_testmod-dependent
> selftest on arm64 would be lost, not only the two new ones. The same
> configuration worked before this patch.
>
> Could the two arm64-hole kfuncs go into a separate kfunc set whose
> registration failure is tolerated? Alternatively, should the commit message
> say that bpf_testmod.ko as a whole needs the newer pahole on arm64, rather
> than "the tests fail to load there"?
There is no need to test with old pahole. Rather we should use latest pahole.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37897160282
next prev parent reply other threads:[~2026-10-09 17:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 6:42 [PATCH bpf-next 0/5] bpf: Follow up by-value struct and __int128 argument support Yonghong Song
2026-10-09 6:42 ` [PATCH bpf-next 1/5] selftests/bpf: Test by-value __int128 kfunc arguments at an odd slot Yonghong Song
2026-10-09 7:48 ` bot+bpf-ci
2026-10-09 17:04 ` Yonghong Song [this message]
2026-10-09 6:42 ` [PATCH bpf-next 2/5] bpf: Keep the BPF calling convention for a trampoline on a BPF function Yonghong Song
2026-10-09 7:26 ` bot+bpf-ci
2026-10-09 17:20 ` Yonghong Song
2026-10-10 15:00 ` Alexei Starovoitov
2026-10-12 6:03 ` Yonghong Song
2026-10-09 6:42 ` [PATCH bpf-next 3/5] bpf, x86: Place trampoline arguments by the x86-64 calling convention Yonghong Song
2026-10-09 7:08 ` sashiko-bot
2026-10-09 17:38 ` Yonghong Song
2026-10-09 6:42 ` [PATCH bpf-next 4/5] selftests/bpf: Test trampoline args around a 16-byte aligned stack arg Yonghong Song
2026-10-09 6:51 ` sashiko-bot
2026-10-09 18:12 ` Yonghong Song
2026-10-09 6:42 ` [PATCH bpf-next 5/5] selftests/bpf: Test trampoline args of a BPF function at an odd slot Yonghong Song
2026-10-09 7:48 ` bot+bpf-ci
2026-10-09 18:17 ` Yonghong Song
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=741a2407-5d2e-44e4-b6a4-241089693a90@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@fb.com \
--cc=martin.lau@kernel.org \
--cc=mason@kernel.org \
/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.