Re: [RFC PATCH bpf-next v1 00/11] Unwinding for synchronous callbacks

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2026-10-28 at 22:42 +0100, Kumar Kartikeya Dwivedi wrote:

...

> There are other various other misc. cases where it is more appropriate
> or necessary:
> - Software CFI-checked indirect calls to subprogs (basically, emitting
> a check on an indirect call (say with pointer from arena) and aborting
> the program when the CFI-like check fails).
> - If runtime stack probing or recursion limits are hit, the program is
> aborted, instead of return 0 (as done in rust-bpf).
> - Making bpf_spin_lock() just work and aborting on deadlocks.
> - When writing actual programs in C++ or Rust, inevitably, panic() may
> be seen (but may not be exercised) in code that is unwinding. The
> verifier will just reject such cases. In both C++ or Rust the behavior
> is to panic=abort or std::terminate(), which is a good analogue for
> simply aborting the program.
> 
> In general, it serves many purposes, has analogue in every other
> virtual machine runtime, thus is a well understood idea, and
> encompasses what various alternative proposals for some of the covered
> use cases do (fast-execute, etc.) but with better semantics.

I agree with Kartikeya on these points.
Unwinding and terminating execution is a well understood and common concept.
It is "in distribution", so to speak.

The new verifier series would benefit from it instead of taking quite
unusual and unexpected actions, like inserting additional control flow exits,
or returning 0 from a subprogram that doesn't have stack space to recur.
"If loop runs for too long the program is terminated" is a much simpler
concept to work with compared to "if loop runs for too long the program
is taking some exit from a loop".

2K LOC is basically nothing, if one assumes that code is maintained by LLM.
There are much more invasive verification concepts atm, like freplace
for parts of the program, or tail calls.

...