Re: [PATCH bpf-next v5 07/21] bpf: Explore the landing pads no call site reaches

[Yonghong Song <yonghong.song@linux.dev>]

On 9/23/26 2:28 PM, Alexei Starovoitov wrote:
> On Wed Sep 23, 2026 at 4:26 PM UTC, Eduard Zingerman wrote:
>> On Tue, 2026-09-22 at 21:59 -0700, Yonghong Song wrote:
>>> A cleanup record need not cover a call an exception can unwind out of: a
>>> frontend is free to emit a region around a helper or an ordinary kfunc,
>>> both nounwind here. Nothing marks a call site then, and that record's
>>> landing pad is reached by nothing at all -- leaving bpf_check_cfg() to
>>> refuse the program over code its own frontend had no way not to emit:
>>>
>>>     0: call bpf_preempt_disable
>>>     1: call bpf_preempt_enable      record = { begin = 1, end = 2, pad = 4 }
>>>     2: r0 = 0
>>>     3: exit
>>>     4: r1 = pads_ran ll             landing pad
>>>     6: r2 = *(u64 *)(r1 + 0)
>>>     7: r2 |= RAN_NOUNWIND_REC
>>>     8: *(u64 *)(r1 + 0) = r2
>>>     9: call bpf_unwind_resume
>>>    10: exit
>>>
>>> The range [1,2) holds one call, and it is a kfunc, so an exception cannot
>>> come out of it. mark_call_sites() marks nothing, nothing pushes an edge to
>>> 4, and 4 through 10 are reachable from nothing: "unreachable insn 4". The
>>> pad is dead, which is correct -- no exception can ever arrive at it -- but
>>> the program is fine and has to load.
>>>
>>> Walk every pad the table names that the edges did not reach, the way the
>>> walk is already re-seeded at an exception callback. From there the pad is
>>> code like any other: do_check() never enters it, because no call site
>>> dispatches to it, so the dead code sweep removes it along with everything
>>> else that was not reached.
>>>
>>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>>> ---
>> Yonghong, in v4 you said that rustc does not generate dead landing pads.
>> Why do we need this patch?
> It's not dead. commit log is incorrect.
>
> I bet C code that caused such asm didn't mark bpf_preempt_enable as nothrow,
> so compiler correctly emitted exception table.
> Now commit log argues that this helper doesn't throw in reality.
> Well, too late, the mistake was made earlier.
>
> I don't like the unwind approach taken by later patches in the series.
>
> imo the following is cleaner:
> - do not repurpose bpf_throw() for this new thing.
>    Introduce new kfunc that will do the unwind, let's name it bpf_unwind() ?
> - replace all 'call bpf_unwind_resume' with NOP by the verifier (or may with bpf_exit. tbd)
>    Technically rustc or llvm can do that too, but it's cleaner to do in the verifier.
> - In bpf_unwind() walk all exception tables and replace return addresses
>    in corresponding frames to landing_pad_ip-s.
> - just return from bpf_unwind().
>    restoring callee saved registers will happen automatically by corresponding
>    frames and there is no need to search exception tables at each step.
>    That's what typical eh unwinder does, but it's doing it due to C++ logic
>    that is more complex that Rust. For Rust unwinds we don't need all that.
>    The above algorithm will do.
>
> Also please add an example where [ip_start, ip_end] range is more than just a call
> insn. I mentioned it couple times as the reason why 'invoke' aka 16-byte insn
> approach doesn't work.
> I'm pretty sure I saw such IP ranges generated by rustc.
>
Thanks for explaining what should be implemented in a simpler way. I will try
to implement this as above steps.