Re: [PATCH bpf-next v7 03/10] bpf: Wire up JIT support for 16-byte kfunc returns

[Yonghong Song <yonghong.song@linux.dev>]

On 8/18/26 11:49 PM, bot+bpf-ci@kernel.org wrote:
>> bpf: Wire up JIT support for 16-byte kfunc returns
>>
>> LLVM 23 returns an __int128, or a struct/union larger than 8 bytes and no
>> larger than 16 bytes, in the BPF R0:R2 register pair. The previous patch
>> added the shared helpers describing that convention; wire up the JIT side
>> so that the second half of the return value actually lands in R2.
>>
>> Placing the second return half into R2 is possible on any JIT, but it needs
>> architecture-specific JIT work. Rather than requiring every JIT to
>> implement it at once, add a bpf_jit_supports_kfunc_ret_reg_pair()
>> capability, defaulting to false in the generic core; an architecture opts
>> in once its JIT handles the R0:R2 pair, and the remaining ones are left for
>> future work. Only the x86-64, arm64 and riscv64 JITs opt in so far.
>>
>> On arm64 and riscv64 the native second return register is already BPF R2
>> (x1 in bpf2a64[] and a1 in regmap[] respectively), so the upper half needs
>> no move at all, unlike x86-64's RDX->RSI. The lower half is covered by the
>> move into BPF R0 that those JITs already emit after every call, from x0
>> into x8 and from a0 into a5. This has been tested on x86-64 and arm64. The
>> riscv64 path is expected to work by the same register-mapping reasoning as
>> arm64 but has not been tested.
>>
>> bpf_add_kfunc_call() also rejects a kfunc that is marked KF_FASTCALL and
>> returns more than 8 bytes. The bpf_fastcall contract implemented by
>> mark_fastcall_pattern_for_call() assumes a call clobbers R0 plus the
>> registers holding its arguments, so a return in the R0:R2 pair would
>> clobber an R2 the caller expects the fastcall pattern to preserve. Such
>> a kfunc is rejected with -EOPNOTSUPP as well.
> This isn't a bug, but could the closing sentence be folded into the opening
> one? The paragraph opens by saying bpf_add_kfunc_call() rejects a
> KF_FASTCALL kfunc that returns more than 8 bytes, and closes with "Such a
> kfunc is rejected with -EOPNOTSUPP as well", which restates the same fact.
> The middle sentence carries the rationale (the fastcall clobber mask covers
> only R0 plus the argument registers, so R2 is assumed preserved), while the
> closing sentence adds only the errno. Something like "... is rejected with
> -EOPNOTSUPP" in the opening sentence would let the paragraph state the
> rejection once and spend its length on the fastcall rationale.

We should be okay here.

>
>
> ---
> 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/32221968339