On 11/17/25 4:49 PM, 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.


We discussed SFrame/JIT topic earlier this year in our monthly SFrame meetings. I can point you to the meeting notes in a separate email. We had some discussion around:

- SFrame specification: Allow efficient addition, removal and update of data in SFrame sections. A part of the challenge is in representing the variety of frames a JIT may use. - SFrame APIs with JIT: Efficient SFrame stack trace data manipulation by JIT. - Interface with Linux kernel: Efficient SFrame stack trace data registration and update stack trace data.

It will be great to have more collaboration and brainstorming, and to include BPF/JIT in the discussions.


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


Reply via email to