BPF stack limit rises to 2KiB on x86-64 and arm64 JITs

BPF programs have long been capped at 512 bytes of stack. Kumar Kartikeya Dwivedi has posted a bpf-next series that raises that budget to 2 KiB for programs JITed on x86-64 and arm64. The interpreter, offloaded programs, and other JITs stay at 512 bytes.

The limit covers a whole call chain, or each frame on a private stack, and a single function may use all of it. Both supported JITs already encode frame sizes in wide immediates and handle tail calls by popping the caller frame before the target sets up its own, so they did not depend on fixed 512-byte frames. The verifier did: jump history, register records, backtracking, scratched-slot logs, id maps, and liveness masks all assumed at most 64 slots per frame. Growing those structures fourfold would have made every program pay for depth most never use.

The series first removes those fixed-size assumptions without changing what verifies, turning liveness masks into bitmaps sized to what each frame actually touches and growing id scratch space on demand. It then introduces a per-program budget of 2 KiB when the program is JITed (not offloaded) and the JIT reports large-stack support with subprogram tail calls, and 512 bytes otherwise, and turns that budget on for x86-64 and arm64.

Tail calls need no separate limit. Callers may still leave at most 256 bytes behind; only the final frame in a chain may grow to 2 KiB, so worst-case kernel stack use rises from about 8.5 KiB to about 10 KiB. Unprivileged programs cannot call other BPF functions, so their worst case remains a single frame. The change matters for complex tracing, networking, and observability programs that previously had to split logic or spill to maps to stay under 512 bytes.