On Wed, Sep 15, 2021 at 05:47:18PM -0400, Steven Rostedt wrote: > On Tue, 14 Sep 2021 17:41:34 -0400 > Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > A better solution, that prevents having to do this, is to first change > > the function fentry's to call the ftrace list loop function, that calls > > the ftrace_ops list, and will call the direct call via the ops in the > > loop. Have the ops->func call the new direct function (all will be > > immediately affected). Update the entries, and then switch from the > > loop back to the direct caller. > > An easy way to force the loop function to be called instead of the direct > trampoline, is to register a stub ftrace_ops to each of the functions that > the direct function attaches to. You can even share the hash in doing so. > > Having the ftrace_ops attached in the same locations as the direct > trampoline, will force the loop function to be called (to call the stub > ftrace_ops as well as the direct trampoline ftrace_ops helper). > > Then change the direct trampoline address, which will have the ftrace_ops > helper use that direct trampoline immediately*. Then when you remove the > ftrace_ops stub, it will update all the call sites to call the new direct > trampoline directly. ok, that's the way the current direct modify interface is using, right? I thought it'd be not so easy to adopt for multiple functions, I'll check on that again and come for help ;-) > > (*) not quite immediately, as there's no read memory barrier with the > direct helper, so it may still be calling the old trampoline. But this > shouldn't be an issue. If it is, then you would need to include some memory > barrier synchronization. > > I'm curious to what the use case is for the multi direct modify interface > is? when the trampoline is re-generated by adding or removing program, we have same functions to trace and new trampoline to attach thanks, jirka > > -- Steve >
