Re: [PATCH bpf-next v4 06/13] bpf: Reject callbacks returning more than 8 bytes

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

On 8/12/26 2:41 PM, Eduard Zingerman wrote:
> On Mon, 2026-08-10 at 17:09 -0700, Yonghong Song wrote:
>> A callback handed to a helper or a kfunc (bpf_loop(),
>> bpf_timer_set_callback(), bpf_for_each_map_elem(), ...) is invoked
>> through bpf_callback_t, and an exception callback is invoked by
>> bpf_throw() through
>>
>>    u64 (*bpf_exception_cb)(u64 cookie, u64 sp, u64 bp, u64, u64);
>>
>> Both prototypes yield a single u64 in R0, and neither caller has any
>> notion of a second return register, so a callback returning a value in
>> the R0:R2 pair would have the upper half of its return value silently
>> dropped.
>>
>> Reject both at load time:
>>
>>   - check_ld_imm(): a callback is materialized as PTR_TO_FUNC by an
>>     ld_imm64 pointing at its subprogram, so the subprogram's return
>>     convention can be checked where the callback pointer is created,
>>     before it ever reaches a helper or kfunc argument.
>>
>>   - do_check_common(): an exception callback is not referenced by a
>>     PTR_TO_FUNC, it is named by a BTF decl_tag and verified on its own,
>>     so check it as its frame is set up, next to the existing "cannot
>>     return void" and single-argument checks.
>>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> ---
> The code itself makes sense to me, but do we really need to check this?

Okay, I will remove this patch. The verifier has some definition for callback
function with returning R0. If callback function (prog) intends to return
two registers, the return register R2 will be ignored.

>
> ...