Steven Rostedt <rostedt@xxxxxxxxxxx> writes: > On Mon, 29 Apr 2019 14:38:35 -0700 > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > >> On Mon, Apr 29, 2019 at 1:30 PM Steven Rostedt <rostedt@xxxxxxxxxxx> 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
