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

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

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.