On Mon, Nov 24, 2025 at 09:14:59AM -0800, Alexei Starovoitov wrote: > On Fri, Nov 21, 2025 at 4:56 PM Josh Poimboeuf <[email protected]> wrote: > > > > > > Maybe we can take advantage of the fact that BPF uses frame pointers > > unconditionally, and avoid the complexity of "dynamic ORC" for now, by > > just having BPF keep track of where the frame pointer is valid (after > > the prologue, before the epilogue). > > ... > > EMIT1(0xC9); /* leave */ > > + bpf_prog->aux->ksym.fp_end = prog - temp; > > + > > emit_return(&prog, image + addrs[i - 1] + (prog - > > temp)); > > break; > > > > @@ -3299,6 +3304,8 @@ static int __arch_prepare_bpf_trampoline(struct > > bpf_tramp_image *im, void *rw_im > > } > > EMIT1(0x55); /* push rbp */ > > EMIT3(0x48, 0x89, 0xE5); /* mov rbp, rsp */ > > + im->ksym.fp_start = prog - (u8 *)rw_image; > > + > > Overall makes sense to me, but do you have to skip the prologue/epilogue ? > What happens if it's just bpf_ksym_find() ? > Only irq can interrupt this push/mov sequence and it uses a different irq > stack.
On x86-64, IRQs actually just use the task stack, but that doesn't really matter: either way ORC needs to unwind through it and it needs to know whether the unwind info is reliable. If BPF gets preempted in the prologue, and ORC just does bpf_ksym_find() and assumes frame pointer, the unwind will either fail outright or skip stack frames. Particularly for the latter case that would break live patching. Today it already tries to fall back to frame pointers for BPF, and that usually works. But it marks the unwind as "unreliable" because it's just a guess. This patch would help mark the typical non-preempted BPF case as "reliable" so it would work with live patching. -- Josh
