Re: [PATCH bpf-next v4 16/25] bpf: Disable private stack for x86_64 if stack arguments used

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

On 5/15/26 7:28 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Hardcoding architecture-specific JIT register limitations into the generic BPF verifier.
> --
>
> commit d388190c12c82279caa212e6edeefb82d873dd00
> Author: Yonghong Song <yonghong.song@linux.dev>
>
> bpf: Disable private stack for x86_64 if stack arguments used
>
> This commit disables private stack support on x86_64 when stack arguments
> are used, because x86-64 uses R9 for both the private stack frame pointer
> and arg6. Other architectures have enough registers to support both.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 47df3f40a71cf..745e13cfb54d6 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -5163,7 +5163,10 @@ static int check_max_stack_depth_subprog(struct bpf_verifier_env *env, int idx,
>>   	}
>>   
>>   	subprog_depth = round_up_stack_depth(env, subprog[idx].stack_depth);
>> -	if (priv_stack_supported) {
>> +	if (IS_ENABLED(CONFIG_X86_64) && subprog[idx].stack_arg_cnt) {
> Is it appropriate to hardcode host architecture macros like
> IS_ENABLED(CONFIG_X86_64) directly into the core verifier logic?
>
> This isn't a bug, but it introduces architecture-specific constraints into the
> generic BPF verifier. Would it be better to handle this by querying JIT backend
> capabilities via a generic API (e.g., passing stack argument requirements to a
> JIT capability checker) so the verifier remains architecture-agnostic?

Disabling private stack support in verifier sounds better. We do have
two cases of '#ifdef CONFIG_X86_64' in verifier.

>
>> +		/* x86-64 uses R9 for both private stack frame pointer and arg6. */
>> +		subprog[idx].priv_stack_mode = NO_PRIV_STACK;
>> +	} else if (priv_stack_supported) {
>>   		/* Request private stack support only if the subprog stack
>>   		 * depth is no less than BPF_PRIV_STACK_MIN_SIZE. This is to
>>   		 * avoid jit penalty if the stack usage is small.