Re: [PATCH bpf-next v1 16/18] bpf, x86: Allow programs 2 KiB of stack

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Wed Sep 23, 2026 at 10:12 PM CEST, bot+bpf-ci wrote:
>> diff --git a/Documentation/bpf/bpf_design_QA.rst b/Documentation/bpf/bpf_design_QA.rst
>> index eb19c945f4d5..be5fc4ac00d6 100644
>> --- a/Documentation/bpf/bpf_design_QA.rst
>> +++ b/Documentation/bpf/bpf_design_QA.rst
>> @@ -221,9 +221,13 @@ newer kernels. BPF programs need to change accordingly when this happens.
>>
>>  Q: How much stack space a BPF program uses?
>>  -------------------------------------------
>> -A: Currently all program types are limited to 512 bytes of stack
>> -space, but the verifier computes the actual amount of stack used
>> -and both interpreter and most JITed code consume necessary amount.
>> +A: A program may use up to 2 KiB of stack, combined over its call
>> +chain, when the JIT of the architecture reports support for large
>> +stacks (currently x86-64); a single function may use all of it, and
>> +every frame of a program running on a private stack gets the whole
>> +amount. Elsewhere, and whenever the interpreter is used, the limit is
>> +512 bytes. The verifier computes the actual amount of stack used and
>> +both interpreter and most JITed code consume necessary amount.
>
> Is the interpreter limit stated correctly here? The text says "whenever
> the interpreter is used, the limit is 512 bytes" in a paragraph where
> 2 KiB is defined as combined over the call chain.
>
> When bpf_jit_supports_large_stack() returns true, a program with
> jit_requested set is verified against MAX_BPF_STACK_JIT (2048) in
> bpf_check() via env->stack_limit = bpf_prog_stack_limit(env->prog), and
> check_max_stack_depth_subprog() bounds the combined depth of the call chain
> by that limit.
>
> If JIT compilation then fails with anything other than -EFAULT (for example,
> a subprogram not being jited returns -ENOTSUPP in bpf_jit_subprogs(), or an
> allocation failure during blinding occurs) and CONFIG_BPF_JIT_ALWAYS_ON is
> not set, bpf_jit_subprogs() restores the instructions, clears
> prog->jit_requested, and bpf_fixup_call_args() falls back to the
> interpreter. The interpreter checks on that path are per frame in
> bpf_patch_call_args():
>
>     int bpf_patch_call_args(struct bpf_insn *insn, u32 stack_depth)
>     {
>         stack_depth = max_t(u32, stack_depth, 1);
>         /* Prevent out-of-bounds read to interpreters_args */
>         if (stack_depth > MAX_BPF_STACK)
>             return -EINVAL;
>
> and bpf_prog_select_interpreter() for the main frame.
>
> A chain of four subprograms each using 512 bytes (2048 combined) would be
> accepted by the verifier and run in the interpreter, whereas before this
> patch the combined chain was capped at 512. Each interpreter frame has its
> own stack array, so this is not an out-of-bounds access. Should the text
> clarify that the interpreter's 512 byte limit applies per function, or
> should the fallback path reject a chain whose combined depth exceeds
> MAX_BPF_STACK?
>

It is indeed slightly confusnig, will reword.

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