From: Yonghong Song <yonghong.song@linux.dev>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Eduard Zingerman <eddyz87@gmail.com>,
kernel-team@fb.com, Alan Maguire <alan.maguire@oracle.com>
Subject: Re: [PATCH bpf-next v3 0/3] bpf: Fix trampoline handling of 128-bit values
Date: Fri, 10 Jul 2026 20:58:15 -0700 [thread overview]
Message-ID: <03358a0d-94bc-407a-8b01-b3dd27c8d46b@linux.dev> (raw)
In-Reply-To: <DJVC4VW0JKXX.1DBERHV6ZVCMX@gmail.com>
On 7/10/26 6:02 PM, Kumar Kartikeya Dwivedi wrote:
> On Sat Jul 11, 2026 at 12:52 AM CEST, Yonghong Song wrote:
>> The BPF trampoline preserves only 8 bytes of a target function's return
>> value (R0), and its register save area under-allocates space for 128-bit
>> arguments for x86_64. These two problems lead to memory corruption or
>> incorrect values observed by BPF programs and the real caller.
>>
>> This series fixes both issues and adds two selftests, otherwise, each of
>> them will fail if without the corresponding fix.
>>
> This is almost ready, but CI currently fails for tracing_struct tests. [0]
>
> My AI agent suggests the following root cause, which sounds like a pahole issue.
>
> "
> • The failure is caused by missing module BTF, not by the trampoline fix itself.
>
> tracing_struct/int128_args fails with -ESRCH because pahole omits
> bpf_testmod_test_int128_arg() from bpf_testmod.ko’s BTF. The failure occurs
> before the BPF program attaches; see .kdev/logs/vm-cmd.log:3.
>
> The problematic signature is tools/testing/selftests/bpf/test_kmods/bpf_testmod.c:184:
>
> bpf_testmod_test_int128_arg(__int128 a, int b, long c)
>
> On x86-64:
>
> - a consumes rdi:rsi.
> - b, the second source parameter, is therefore in rdx.
> - pahole maps the second parameter positionally to rsi, sees b in rdx, and
> marks the function as having unexpected register usage.
> - Kernel BTF generation enables consistent_func, so the complete function is
> omitted from BTF (scripts/Makefile.btf:17).
>
> Verbose pahole confirmed:
>
> bpf_testmod_test_int128_arg : skipping BTF encoding of function due to unexpected register usage for parameter
>
> This also means the comment claiming that putting __int128 first prevents the pahole issue is incorrect.
>
> A scratch probe with the exact kdev Clang and pahole showed:
>
> int128_first : skipping BTF encoding ...
> FUNC int128_last ...
>
> The likely test correction is to use:
>
> bpf_testmod_test_int128_arg(int b, long c, __int128 a)
>
> and update tools/testing/selftests/bpf/progs/tracing_struct_int128.c:12 to
> read b from ctx[0], c from ctx[1], and the return value from ctx[4]. With two
> preceding scalar registers, the 128-bit argument starts at an even register
> pair on arm64 too. This still exercises the four-slot allocation that the x86
> patch fixes.
> "
>
> [0]: https://github.com/kernel-patches/bpf/pull/12778
Thanks, Kumar,
This indeed is a pahole issue. My local test is working because my local pahole
has the following patch set:
pahole: Encode true signatures in kernel BTF
https://lore.kernel.org/bpf/20260625020148.1883082-1-yonghong.song@linux.dev/
With this, e.g, running selftest like './test_progs -t tracing_struct' will succeed
for both clang21 and gcc15.
Without the above pahole patch set (pahole: Encode true signatures in kernel BTF),
the 'tracing_struct' test will fail with either llvm21 or gcc15:
libbpf: prog 'test_int128_arg_fexit': failed to find kernel BTF type ID of 'bpf_testmod_test_int128_arg': -ESRCH
libbpf: prog 'test_int128_arg_fexit': failed to prepare load attributes: -ESRCH
libbpf: prog 'test_int128_arg_fexit': failed to load: -ESRCH
libbpf: failed to load object 'tracing_struct_int128'
libbpf: failed to load BPF skeleton 'tracing_struct_int128': -ESRCH
test_int128_args:FAIL:tracing_struct_int128__open_and_load unexpected error: -3
#539/3 tracing_struct/int128_args:FAIL
So in order to unblock this patch set, the pahole patch set
pahole: Encode true signatures in kernel BTF
should be merged soon (maybe after some minor adjustment).
I will contact Alan for this as I will take some time off in the next couple of weeks.
>
>> Changelogs:
>> v2 -> v3:
>> - v2: https://lore.kernel.org/bpf/20260710182204.1085329-1-yonghong.song@linux.dev/
>> - Align __int128 argument at even position enforced by arm64.
>> v1 -> v2:
>> - v1: https://lore.kernel.org/bpf/20260710144404.2579671-1-yonghong.song@linux.dev/
>> - Also handle __int128 arguments for x86_64.
>>
>> Yonghong Song (3):
>> bpf: Reject >8 byte return values on return-reading trampoline paths
>> bpf, x86: Fix trampoline stack size for 128-bit arguments
>> selftests/bpf: Add tests for >8 byte return value and 128-bit
>> arguments
>>
>> arch/x86/net/bpf_jit_comp.c | 7 ++--
>> kernel/bpf/bpf_struct_ops.c | 12 +++++++
>> kernel/bpf/verifier.c | 25 +++++++++++++
>> .../bpf/prog_tests/tracing_failure.c | 12 +++++++
>> .../selftests/bpf/prog_tests/tracing_struct.c | 36 +++++++++++++++++++
>> .../selftests/bpf/progs/tracing_failure.c | 6 ++++
>> .../bpf/progs/tracing_struct_int128.c | 18 ++++++++++
>> .../selftests/bpf/test_kmods/bpf_testmod.c | 32 +++++++++++++++++
>> 8 files changed, 143 insertions(+), 5 deletions(-)
>> create mode 100644 tools/testing/selftests/bpf/progs/tracing_struct_int128.c
next prev parent reply other threads:[~2026-07-11 3:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 22:52 [PATCH bpf-next v3 0/3] bpf: Fix trampoline handling of 128-bit values Yonghong Song
2026-07-10 22:52 ` [PATCH bpf-next v3 1/3] bpf: Reject >8 byte return values on return-reading trampoline paths Yonghong Song
2026-07-10 22:52 ` [PATCH bpf-next v3 2/3] bpf, x86: Fix trampoline stack size for 128-bit arguments Yonghong Song
2026-07-10 22:52 ` [PATCH bpf-next v3 3/3] selftests/bpf: Add tests for >8 byte return value and " Yonghong Song
2026-07-11 1:02 ` [PATCH bpf-next v3 0/3] bpf: Fix trampoline handling of 128-bit values Kumar Kartikeya Dwivedi
2026-07-11 3:58 ` Yonghong Song [this message]
2026-07-11 12:18 ` Leon Hwang
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=03358a0d-94bc-407a-8b01-b3dd27c8d46b@linux.dev \
--to=yonghong.song@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=kernel-team@fb.com \
--cc=memxor@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