Re: [PATCH bpf-next v2 09/20] bpf: Refuse a private stack for a program with an exception cleanup table

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

On 9/17/26 10:44 PM, bot+bpf-ci@kernel.org wrote:
>> A landing pad is about to start running outside its own frame, on the
>> bpf_throw() walker's stack, with that frame's registers put back from a
>> spill area whose contents arch_bpf_run_cleanup_pad() knows how to read. The
>> x86-64 JIT addresses a private-stack program's frame through a scratch
>> register that it recomputes after each call rather than through rbp, and no
>> spill area holds that register, so a pad there would address its frame
>> through whatever the kernel left behind.
> The description says the x86-64 JIT 'recomputes after each call'. Does the
> JIT actually recompute it?
>
> Looking at the x86 JIT, emit_priv_frame_ptr() (arch/x86/net/bpf_jit_comp.c)
> is emitted once in the prologue, and the value in X86_REG_R9 is carried
> across calls by push_r9()/pop_r9() around each call site; BPF_REG_FP
> accesses are rewritten to X86_REG_R9.
>
> The load-bearing half of the argument is still correct -
> arch_bpf_run_cleanup_pad() (added later in the series,
> arch/x86/net/bpf_cleanup_pad.S) restores only r15/r14/r13/rbx/r12 and rbp
> from the spill area and never restores r9, so a pad in a private-stack
> program would address its frame through a stale register.
>
> Only the described mechanism (recompute vs save/restore around calls) is
> wrong, which makes the justification harder to check against the JIT.
>
>> Everywhere rather than arch-conditionally: arm64 keeps its private
>> stack pointer in x27, which is in the prologue spill and so survives, but a
>> rule that holds on one arch and not the other is not worth the second code
>> path when nothing is lost but an optimization.
> Does 'nothing is lost but an optimization' understate the effect?
>
> The private-stack mode also changes the verifier's stack-depth accounting,
> not just JIT codegen. In check_max_stack_depth_subprog() a
> PRIV_STACK_ADAPTIVE subprog is checked against MAX_BPF_STACK on its own ('if
> (subprog_depth > MAX_BPF_STACK)'), while a NO_PRIV_STACK subprog accumulates
> into 'depth' and the whole bpf2bpf chain must fit in MAX_BPF_STACK
> ('combined stack size of %d calls is %d. Too large').
>
> So for the prog types bpf_enable_priv_stack() would have returned
> PRIV_STACK_ADAPTIVE for (kprobe/tracepoint/perf_event/raw_tp, and
> tracing/lsm/struct_ops with a recursion or an explicit request), a program
> carrying a cleanup table whose nested subprog depths sum above 512 bytes now
> fails to load rather than losing performance.
>
> Worth stating in the changelog, since it is a load-time visible restriction
> on the new feature rather than an optimization.

Okay, comments and commit message may have some stale things or something
like (when nothing is lost but an optimization) is not correct. Will fix.

>
> Related: kernel/sched/ext/ext.c sets prog->aux->priv_stack_requested for
> sched_ext dispatch/sub_caps_updated, and verifier.c rejects such a request
> when the JIT cannot honour it; here the request is silently ignored instead.
>
> This looks like a bug fix for private stack support. Should this include:
>
>    Fixes: a76ab5731e32d ("bpf: Find eligible subprogs for private stack support")

Fixes tag is unnecessary.

>
>
> ---
> 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/35308528711