Re: [PATCH v2 bpf-next 0/5] bpf: Unwinding with unwind_goto and unwind_exit

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

On Mon, Oct 19, 2026 at 01:32 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> As far as I understand, the main difference from what was discussed in [1]
> is that for nested calls of functions that can unwind, each function
> in a chain must be called as call/unwind_goto pair, right?

Right. Otherwise prepare_func_exit() rejects unwind_exit of the callee.

> LLVM IR does not have such limitation: `call` and `invoke` calls can
> be mixed in a chain. What the limitation buys is an ability to skip
> the loop like [2] in the verifier.

It buys more than that. Every frame returns through its own epilogue,
so r6-r9 are restored by the frame that saved them, and there is no
stack walk at run time.

> Is it planned to add an LLVM pass that converts all `call`s to
> `invoke`s for unwinding functions?

No need for a new pass. The llvm PR does it already: a plain call that
can unwind gets unwind_goto to a pad with 'r0 = 0; unwind_exit'.
does_not_catch() in patch 5 is such a case.

> If I read the series correctly before the replacement runtime control
> flow would follow `unwind_goto pad`, but after the replacement it
> would follow the normal continuation flow.
> Is it intentional? Seem to be a surprising behavior.

Yes, you read it right. An extension is a main prog of its own and
unwind_exit of the main prog is exit: it's frame 0 in the verifier and
bpf_is_subprog() is false in JITs. So the exception stops at the
extension, and the caller continues as if foo returned r0.

> Commit message says:
>
>   > So is freplace: an extension leaves with exit and
>   > the callers are ready for that.
>
> But I'm not sure I understand that.

foo can unwind, so check_func_call() made the verifier explore both
ways out of the call. The normal continuation is checked with an
unknown r0, so it's safe whatever the extension does.
Works out of the box, but maybe it's easier to disable freplace for now.