Re: [PATCH bpf-next v3 08/11] selftests/bpf: Check the member named for an unsupported kfunc return type

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

On 8/27/26 12:04 AM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/testing/selftests/bpf/progs/aggregate_ret_kfunc.c b/tools/testing/selftests/bpf/progs/aggregate_ret_kfunc.c
>> index f10e5cf6fd890..e9c82df8efb26 100644
>> --- a/tools/testing/selftests/bpf/progs/aggregate_ret_kfunc.c
>> +++ b/tools/testing/selftests/bpf/progs/aggregate_ret_kfunc.c
> [ ... ]
>
>> @@ -72,6 +74,7 @@ __naked int aggregate_ret_kfunc_fastcall_fail(void)
>>   SEC("tc")
>>   __arch_x86_64 __arch_arm64
>>   __failure __msg("is not composed of scalars or arena pointers")
>> +__msg("member 'p' has type PTR")
>>   __naked int aggregate_ret_kfunc_ptr_fail(void)
> [ ... ]
>
>> @@ -84,6 +87,37 @@ __naked int aggregate_ret_kfunc_ptr_fail(void)
>>   	: __clobber_all);
>>   }
>>
>> +SEC("tc")
>> +__arch_x86_64 __arch_arm64
>> +__failure __msg("is not composed of scalars or arena pointers")
>> +__msg("member 'in.p' has type PTR")
>> +__naked int aggregate_ret_kfunc_nested_ptr_fail(void)
> [ ... ]
>
>> +SEC("tc")
>> +__arch_x86_64 __arch_arm64
>> +__failure __msg("max struct nesting depth exceeded")
>> +__naked int aggregate_ret_kfunc_too_deep_fail(void)
>> +{
>> +	asm volatile (
>> +	"r1 = 0;"
>> +	"call %[bpf_kfunc_call_test_ret_deep];"
>> +	"r0 = 0;"
>> +	"exit;"
>> +	:
>> +	: __imm(bpf_kfunc_call_test_ret_deep)
>> +	: __clobber_all);
>> +}
> A subsystem pattern flags this as potentially concerning: the commit
> message states the third case covers "a type nested deeper than the
> walk descends, which has no single member to blame and reports the
> depth instead." But the test's only assertion, __msg("max struct
> nesting depth exceeded"), pins a string that predates the series.
>
> Looking at the verifier code, the depth report text ' It nests structs
> more than %d levels deep.' was added by commit b99471ca9c385, and
> unlike the member case there is no verbose() counterpart for it - it
> is only emitted through bpf_diag_program_structure(). This diagnostic
> output is reachable to __msg since libbpf retries a failed load at
> log_level 1.
>
> If the new path->too_deep assignment and the entire 'if (path.too_deep)'
> branch were deleted, path.depth would still be 0 (the too-deep return
> bypasses the bad_member/bad_path labels), member_note would stay "",
> and nothing else would change in the log. The test would still pass even
> though the new behavior was not present.
>
> The two sibling tests don't have this problem - 'member 'p' has type
> PTR' and 'member 'in.p' has type PTR' are both new strings from
> b99471ca9c385 and directly verify that the kernel names the member
> correctly. The too_deep test also omits the __msg("is not composed of
> scalars or arena pointers") anchor that both siblings carry, so it does
> not even pin that the failure came from the kfunc-return path.
>
> Would adding an assertion on the depth diagnostic text plus the anchor
> message make the case more discriminating?

I would like to keep it as is. For path.too_deep, we do not need to
have member names. The user only needs to take a look at the top
struct which is already available.

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