BPF stack limit proposed to rise from 512 bytes to 2 KiB
x86-64 and arm64 JITs would get the larger budget; the interpreter and other architectures stay at 512 bytes.
BPF programs have been capped at 512 bytes of stack for years. Kumar Kartikeya Dwivedi has posted an 18-part series on the BPF development list that would raise that limit to 2 KiB for programs JITed on x86-64 and arm64.
The change targets a long-standing constraint on complex programs: deep call chains, large locals, and private-stack frames often bump into the 512-byte wall. Under the proposal a single function may use the full 2 KiB. The budget covers either an entire call chain or each frame on a private stack. Interpreted programs, offloaded programs, and JITs that do not opt in keep 512 bytes.
The verifier is the hard part. Several of its structures assume at most 64 slots per frame, so a naive fourfold growth would make every load pay for stack depth most programs never use. The series first makes liveness masks and id bookkeeping grow with the stack a frame actually touches, then adds a per-program budget granted only when the JIT reports large-stack support (and subprogram tail calls). Fixed and variable stack accesses, unprivileged pointer arithmetic, and combined depth checks all follow that budget.
Tail-call chains need no separate limit. Callers of a tail call still leave at most 256 bytes behind; only the final frame expands, so worst-case kernel stack use rises from roughly 8.5 KiB to about 10 KiB on a typical 16 KiB stack. Privilege does not change the budget: an unprivileged program cannot call other BPF functions, so its worst case is one 2 KiB frame. Nested programs entered through helpers remain unaccounted against each other; each nesting level may add up to 1.5 KiB more than before.
Peak verifier memory across more than five thousand loadable selftests rose only slightly overall, with a few loop-heavy cases growing more. Design documentation and selftests are updated for both the old and new boundaries. Dwivedi agreed an automated review point on out-of-memory handling during reference release needs more graceful treatment before the work lands.