On 08/10/25 1:43 pm, Naveen N Rao wrote:

On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:

quoted

On 06/10/25 1:22 pm, Naveen N Rao wrote:

quoted

On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:

quoted

Today, livepatch takes precedence over direct_call. Instead, save the
state and make direct_call before handling livepatch.

If we call into the BPF trampoline first and if we have
BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
calling the new copy of the live-patched function or the old one?

Naveen, calls the new copy of the live-patched function..

Hmm... I'm probably missing something.

With ftrace OOL stubs, what I recall is that BPF trampoline derives the
original function address from the OOL stub (which would be associated
with the original function, not the livepatch one).

Trampoline derives the address from LR. The below snippet
in livepatch_handler ensures the trampoline jumps to '1f'
label instead of the original function with LR updated:

+	/* Jump to the direct_call */
+	bnectrl	cr1
+
+	/*
+	 * The address to jump after direct call is deduced based on ftrace 
OOL stub sequence.
+	 * The seemingly insignificant couple of instructions below is to 
mimic that here to
+	 * jump back to the livepatch handler code below.
+	 */
+	nop
+	b	1f
+
+	/*
+	 * Restore the state for livepatching from the livepatch stack.
+	 * Before that, check if livepatch stack is intact. Use r0 for it.
+	 */
+1:	mtctr	r0


- Hari