Hi Joanne, > Looking at arch/arm64/net/bpf_jit_comp.c, I see this diagram > > /* > * BPF prog stack layout > * > * high > * original A64_SP => 0:+-----+ BPF prologue > * |FP/LR| > * current A64_FP => -16:+-----+ > * | ... | callee saved registers > * BPF fp register => -64:+-----+ <= (BPF_FP) > * | | > * | ... | BPF prog stack > * | | > * +-----+ <= (BPF_FP - prog->aux->stack_depth) > * |RSVD | padding > * current A64_SP => +-----+ <= (BPF_FP - ctx->stack_size) > * | | > * | ... | Function call stack > * | | > * +-----+ > * low > * > */ > It looks like prog->aux->stack_depth is used for the "BPF prog stack", > which is the stack for the main bpf program (subprog 0) Thanks for looking into this. Also note the verifier.c:jit_subprogs function which essentially "promotes" every sub-program to sub-program #0 before calling bpf_jit_comp.c:bpf_int_jit_compile for that sub-program. > I'm not sure either whether MAX_BPF_STACK is a hard limit or a soft > limit. I'm curious to know as well. Alexei had commented in a sibling thread that MAX_BPF_STACK should be considered a soft limit. Thanks, Eduard
