Steven Rostedt rostedt@goodmis.org writes:
On Mon, 29 Apr 2019 14:38:35 -0700 Linus Torvalds torvalds@linux-foundation.org wrote:
On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt rostedt@goodmis.org wrote:
The update from "call custom_trampoline" to "call iterator_trampoline" is where we have an issue.
So it has never worked. Just tell people that they have two chocies:
The custom call to iterator translation never worked. One option is to always call the iterator, and just take the hit. There's another solution to to make permanent updates that would handle the live patching case, but not for the tracing case. It is more critical for live patching than tracing (missed traced function is not as critical as running buggy code unexpectedly). I could look to work on that instead.
Making the live patching case permanent would disable tracing of live patched functions though?
For unconditionally calling the iterator: I don't have numbers, but would expect that always searching through something like 50-70 live patching ftrace_ops from some hot path will be noticeable.
If Nicolai has time, perhaps he can try out the method you suggest and see if we can move this forward.
You mean making ftrace handle call->call transitions one by one in non-batch mode, right? Sure, I can do that.
Another question though: is there anything that prevents us from calling ftrace_ops_list_func() directly from ftrace_int3_handler()? We don't have parent_ip, but if that is used for reporting only, maybe setting it to some ftrace_is_in_int3_and_doesnt_now_the_parent() will work? Graph tracing entries would still be lost, but well...
Thanks,
Nicolai