Re: [PATCH bpf-next v2 1/2] selftests/bpf: Keep int return type for tailcall subprogs

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

On 6/9/26 5:07 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf2.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf2.c
>> index ce97d141daee..c4fadee5aadc 100644
>> --- a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf2.c
>> +++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf2.c
> [ ... ]
>
>> diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_hierarchy2.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_hierarchy2.c
>> index ae94c9c70ab7..6fde0ab92148 100644
>> --- a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_hierarchy2.c
>> +++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf_hierarchy2.c
>> @@ -25,8 +25,11 @@ int count1 = 0;
>>   static __noinline
>>   int subprog_tail0(struct __sk_buff *skb)
>>   {
>> +	int ret = 0;
>> +
>>   	bpf_tail_call_static(skb, &jmp_table, 0);
>> -	return 0;
>> +	barrier_var(ret);
>> +	return ret;
>>   }
>>
>>   __auxiliary
>>   SEC("tc")
>>   int classifier_0(struct __sk_buff *skb)
>>   {
>>   	count0++;
>>   	subprog_tail0(skb);
>>   	return 0;
>>   }
> The patch adds barrier_var() to subprog_tail0() to prevent the compiler
> from optimizing its return type from int to void. However, is the
> approach sufficient for classifier_0()?
>
> Looking at how the patch handles other callers like classifier_1():
>
>> @@ -41,16 +44,22 @@ int classifier_0(struct __sk_buff *skb)
>>   static __noinline
>>   int subprog_tail1(struct __sk_buff *skb)
>>   {
>> +	int ret = 0;
>> +
>>   	bpf_tail_call_static(skb, &jmp_table, 1);
>> -	return 0;
>> +	barrier_var(ret);
>> +	return ret;
>>   }
>>
>>   __auxiliary
>>   SEC("tc")
>>   int classifier_1(struct __sk_buff *skb)
>>   {
>> +	int ret;
>> +
>>   	count1++;
>> -	subprog_tail1(skb);
>> +	ret = subprog_tail1(skb);
>> +	__sink(ret);
>>   	return 0;
>>   }
> In classifier_1(), the return value is captured and passed to __sink().
> This creates a use at the callsite that forces the compiler to preserve
> the int return type.
>
> Without capturing and sinking the return value in classifier_0(), could
> LLVM still create a void-returning clone of subprog_tail0() for this
> specific callsite? While subprog_tail0() is also called from
> tailcall_bpf2bpf_hierarchy_2() where its return value is properly sunk,
> the compiler might still specialize the function differently for the two
> callsites.

We should be fine. In the same file, we have  SEC("tc")

__success
__retval(33)
SEC("tc")
int tailcall_bpf2bpf_hierarchy_2(struct __sk_buff *skb)
{
         int ret = 0, ret1, ret2;

         clobber_regs_stack();

         ret1 = subprog_tail0(skb);
         ret2 = subprog_tail1(skb);
         __sink(ret1);
         __sink(ret2);
         __sink(ret);
         return (count1 << 16) | count0;
}

This will guarantee subprog_tail0() will have a return value.


>
> [ ... ]
>
>
> ---
> 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/27243286945