On Tue, Nov 18, 2025 at 1:10 AM Josh Poimboeuf <[email protected]> wrote: > > On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote: > > On Mon, 17 Nov 2025 15:06:32 -0800 > > Josh Poimboeuf <[email protected]> wrote: > > > > > 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. > > > > > > [*] with one exception: the task calling into livepatch > > > > It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY > > (and definitely with PREEMPT_RT) BPF programs can be preempted. > > In that case, then yes, that stack would be marked unreliable and > livepatch would have to go try and patch the task later. > > If it were an isolated case, that would be fine, but if BPF were > consistently on the same task's stack, it could stall the completion of > the livepatch indefinitely. > > I haven't (yet?) heard of BPF-induced livepatch stalls happening in > reality, but maybe it's only a matter of time :-/ > > To fix that, I suppose we would need some kind of dynamic ORC > registration interface. Similar to what has been discussed with > sframe+JIT.
I work with the BPF JITs and would be interested in exploring this further, can you point me to this discussion if it happened on the list. > > If BPF were to always use frame pointers then there would be only a very > limited set of ORC entries (either "frame pointer" or "undefined") for a > given BPF function and it shouldn't be too complicated. > > -- > Josh
