On 08/10/25 1:43 pm, Naveen N Rao wrote:
On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
On 06/10/25 1:22 pm, Naveen N Rao wrote:
On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
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
