]> git.proxmox.com Git - mirror_ubuntu-eoan-kernel.git/commit
ftrace: Fix up trampoline accounting with looping on hash ops
authorSteven Rostedt (Red Hat) <rostedt@goodmis.org>
Thu, 21 Aug 2014 03:57:04 +0000 (23:57 -0400)
committerSteven Rostedt <rostedt@goodmis.org>
Fri, 22 Aug 2014 19:24:12 +0000 (15:24 -0400)
commitbce0b6c51ac76fc0e763262a6c2a9d05e486f0d8
tree1510bdb140f99c06c660b3606f9c06bf274307fc
parent84261912ebee41269004e8a9f3614ba38ef6b206
ftrace: Fix up trampoline accounting with looping on hash ops

Now that a ftrace_hash can be shared by multiple ftrace_ops, they can dec
the rec->flags by more than once (one per those that share the ftrace_hash).
This means that the tramp_hash may not have a hash item when it was added.

For example, if two ftrace_ops share a hash for a ftrace record, and the
first ops has a trampoline, when it adds itself it will set the rec->flags
TRAMP flag and increments its nr_trampolines counter. When the second ops
is added, it must clear that tramp flag but also decrement the other ops
that shares its hash. As the update to the function callbacks has not yet
been performed, the other ops will not have the tramp hash set yet and it
can not be used to know to decrement its nr_trampolines.

Luckily, the tramp_hash does not need to be used. As the ftrace_mutex is
held, a ops with a trampoline to a record during an update of another ops
that shares the record will have its func_hash pointing to it. Since a
trampoline can only be set for a record if only one ops is attached to it,
we can just check if the record has a trampoline (the FTRACE_FL_TRAMP flag
is set) and then find the ops that has this record in its hashes.

Also added some output to help debug when things go wrong.

Cc: stable@vger.kernel.org # 3.16+ (apply after 3.17-rc4 is out)
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
kernel/trace/ftrace.c