BPF exception cleanups unlock Rust Drop on bpf_throw() unwind

bpf_throw() has long discarded every intermediate BPF frame without letting it release what it owns. The verifier therefore blocked throws from any frame holding an RCU read lock, a preemption-disabled region, or a referenced kernel pointer. That same gap kept Rust BPF programs from using bpf_throw() as a panic path: Drop glue is the give-back, and there was nowhere to run it.

Yonghong Song has posted a bpf-next series that supplies the kernel half of the fix. LLVM 23 already lowers a value held across an unwindable call into an invoke plus a cleanup landing pad, and writes a flat .bpf_cleanup table of begin/end/landing-pad offsets. The series accepts that table at program load, teaches the verifier that a covered call may also reach its pad, and has bpf_throw() run each pad before discarding the frame. Pads terminate with bpf_unwind_resume, the kfunc that stands in for the compiler's _Unwind_Resume.

libbpf parses the section, resolves the code-section relocations, rejects overlapping ranges, and passes the per-program table on both ordinary and light-skeleton loads. JIT support on x86-64 and arm64 lets a pad address its own frame and resume the walk. C has no native unwinding, so the selftests hand-write the same shapes a frontend would emit, including unlock-on-unwind paths the verifier used to reject outright.

The result is that a BPF frame can throw while still holding a resource and still give it back. That is the missing piece for Rust panic and Drop inside the BPF VM, and for any C helper pattern that needs structured cleanup on the exception path.