BPF stack limit poised to rise from 512 bytes to 2 KiB

BPF programs have been capped at 512 bytes of stack for years. Kumar Kartikeya Dwivedi has posted a series that would raise that budget to 2 KiB for JITed programs on x86-64 and arm64, leaving the interpreter, offloaded programs, and other JITs on the old limit.

The change matters for anyone writing non-trivial BPF: complex call chains, larger locals, and deeper helper work often bump into the 512-byte wall. Under the proposal a single function may consume the full 2 KiB, and the same budget covers an entire call chain (or each frame on a private stack).

The hard part is the verifier. Its bookkeeping long assumed at most 64 stack slots per frame, so a naive fourfold expansion would inflate memory for every load, including small programs that never need the extra room. Dwivedi’s series first replaces fixed masks and tables with structures that grow with actual use, then introduces a per-program stack limit that is 2 KiB only when the JIT both supports large frames and can handle tail calls from subprograms.

Tail-call chains stay bounded. Callers may still leave at most 256 bytes of frames behind; only the final program’s frame grows, so worst-case kernel stack use for a long chain rises from roughly 8.5 KiB to about 10 KiB. Unprivileged programs receive the larger budget too, but they cannot call other BPF functions, so their worst case remains a single 2 KiB frame.

Selftests gain load conditions that select 512-byte or 2 KiB expectations depending on what the running kernel and JIT actually grant. No architecture enables the larger budget until the final patches turn it on for x86-64 and arm64.