BPF adds unwind landing pads for resource cleanup

Yonghong Song has posted kernel and libbpf work that lets BPF programs run cleanup landing pads during unwind, the missing piece for Rust-style resource release on panic.

Today bpf_throw() walks the call stack to an exception boundary and discards every frame in between. A frame that owns an RCU read lock, a preemption-disabled section, or a referenced kernel pointer never gets to give it back, so the verifier refuses to let such a frame throw at all. That is why a Rust BPF program cannot treat bpf_throw() as its panic path: Drop glue is exactly that give-back, and there is nowhere to run it.

LLVM 23 already supplies the compiler half. A function that owns a value across a call that can unwind lowers to an invoke with a cleanup pad, and the BPF backend records each region as a begin, end, and landing-pad triple in a .bpf_cleanup section. Song's series is the kernel half: parse that table at program load, teach the verifier to follow an unwind to the pad it reaches, and introduce bpf_unwind() as the kfunc that raises this path. bpf_throw() keeps its existing meaning (leave for the exception boundary with intervening frames discarded). Pads finish by calling a resume helper the kernel provides.

C has no unwinding, so the selftests build the same shape by hand: labeled call sites, explicit pads, and cleanup records, including multi-frame chains that hold RCU or preemption state, cases the kernel must refuse, and loading through light skeletons. Runtime dispatch covers the major JITs.

The change removes a hard barrier between BPF's exception model and languages that expect deterministic cleanup on unwind, without overloading the older throw path.