On Mon, Dec 08, 2025 at 10:05:44PM +0530, Hari Bathini wrote: > > > > 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
