On Tue, Nov 18, 2025 at 01:49:06AM +0100, Puranjay Mohan wrote: > 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.
Sorry, nothing specific has been discussed that I'm aware of :-) -- Josh
