On Tue, Nov 18, 2025 at 12:06 AM Josh Poimboeuf <[email protected]> wrote: > > On Fri, Nov 14, 2025 at 10:50:16PM -0800, Dylan Hatch wrote: > > On Mon, Sep 29, 2025 at 12:55 PM Puranjay Mohan <[email protected]> > > wrote: > > > > > > I will try to debug this more but am just curious about BPF's > > > interactions with sframe. > > > The sframe data for bpf programs doesn't exist, so we would need to > > > add that support > > > and that wouldn't be trivial, given the BPF programs are JITed. > > > > > > Thanks, > > > Puranjay > > > > From what I can tell, the ORC unwinder in x86 falls back to using > > frame pointers in cases of generated code, like BPF. Would matching > > this behavior in the sframe unwinder be a reasonable approach, at > > least for the purposes of enabling reliable unwind for livepatch? > > The ORC unwinder marks the unwind "unreliable" if it has to fall back to > frame pointers. > > But that's not a problem for livepatch because it only[*] unwinds > blocked/sleeping tasks, which shouldn't have BPF on their stack anyway. >
BPF programs can sleep, so wouldn't they show up in the stack? Like if I am tracing a syscall with a bpf program attached using fentry and the BPF program calls a bpf_arena_alloc_pages(), which can sleep.
