On Mon, Dec 08, 2025 at 10:05:44PM +0530, Hari Bathini wrote:

quoted

One of the other thoughts I had was if we could stuff the function
address into the ftrace OOL stub. I had considered this back when I
implemented the OOL stubs, but didn't do it due to the extra memory
requirement. However, given the dance we're having to do, I'm now
thinking that may make sense and can simplify the code. If we can also
hook into livepatch, then we should be able to update the function
address in the stub to point to the new address and the trampoline
should then "just work" since it already saves/restores the TOC [We may
additionally have to update the function IP in _R12, but that would be a
minor change overall]

We will still need a way to restore livepatch TOC if the BPF trampoline
doesn't itself call into the function, but we may be able to handle that
if we change the return address to jump to a stub that restores the TOC
from the livepatch stack.

Sounds doable. Looking into a couple of other things at the moment
though. Will try out this suggestion and get back post that.
Having said that, your thoughts on whether the current approach
is a viable option if bpf_get_func_ip() can be fixed somehow?

Oh, that's fine -- feel free to go with whatever approach you think 
works best.


- Naveen