Messages in this thread | | | Date | Wed, 12 Apr 2017 09:18:21 -0400 | From | Steven Rostedt <> | Subject | Re: There is a Tasks RCU stall warning |
| |
On Tue, 11 Apr 2017 20:23:07 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> But another question... > > Suppose someone traced or probed or whatever a call to (say) > cond_resched_rcu_qs(). Wouldn't that put the call to this > function in the trampoline itself? Of course, if this happened, > life would be hard when the trampoline was freed due to > cond_resched_rcu_qs() being a quiescent state.
Not at all, because the trampoline happens at the beginning of the function. Not in the guts of it (unless something in the guts was traced). But even then, it should be fine as the change was already made.
/* unhook trampoline from function calls */ unregister_ftrace_function(my_ops);
synchronize_rcu_tasks();
kfree(my_ops->trampoline);
Thus, once the unregister_ftrace_function() is called, no new entries into the trampoline can happen. The synchronize_rcu_tasks() is to move those that are currently on a trampoline off.
Is there a way that a task could be in the middle of cond_resched_rcu_qs() and get preempted by something while on the ftrace trampoline, then the above "unregister_ftrace_function()" and "synchronize_rcu_tasks()" can be called and finish, while the one task is still on the trampoline and never finished the cond_resched_rcu_qs()?
> > Or is there something that takes care to avoid putting calls to > this sort of function (and calls to any function calling this sort > of function, directly or indirectly) into a trampoline?
The question is, if its on the trampoline in one of theses functions when synchronize_rcu_tasks() is called, will it still be on the trampoline when that returns?
-- Steve
| |