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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed Oct 28, 2026 at 11:12 PM UTC, Eduard Zingerman wrote:
> 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.

I agree with it as well.
My objection was to 'Eliminate spill overhead for bpf_throw()'
as a pointless step _today_. If we can make bpf_throw() into works-everywhere
mechanism then let's do it, but it has to be that first step.
Polishing 'spill oveheard' is very much optional follow up.

> It is "in distribution", so to speak.

'in distribution' is so early AI lingvo. I hope it's obvious now
that 'in distribution' is the opposite of what is needed to
build secure sw stack.

> 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".

Yes, but the base line is different now. goal posts have moved a lot.

> 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.

it's fine if it's 2k->20k lines too.

Before we do the happy dance pls read section 8
https://lore.kernel.org/all/20261026025943.404450-70-alexei.starovoitov@gmail.com/
It needs to support all 3:

1.
  do { p = lookup(hash map); } while (!p);
  return *p;

2.
  lock(&v->l);
  do { v->cnt++; } while (v->flag);
  unlock(&v->l);
  return 1;

3.
  rcu_read_lock();
  do { p = lookup(hash map); } while (!p);
  x = *p;
  rcu_read_unlock();

The patches I sent don't support 3rd yet. I left it for the follow up.

I'm more than happy to drop may_goto approach,
but I want to see the patches for bpf_throw-that-works-everywhere,
including 3rd case above.
And bpf_throw shouldn't skip rust landing pads.
That's a bar.

Also time is an essence.
We cannot sit and debate things like we did in the past.
If there is code that satisfies the goals that we set, we should be landing it.
How it achieves the gaols is a minor detail at this point.