Linus,
Adding the new code for 3.19, I discovered a couple of minor bugs with
the accounting of the ftrace_ops trampoline logic. One was that the
old hash was not updated before calling the modify code for an ftrace_ops.
The second bug was what let the first bug go unnoticed, as the update would
check the current hash for all ftrace_ops (where it should only check the
old hash for modified ones). This let things work when only one ftrace_ops
was registered to a function, but could break if more than one was
registered depending on the order of the look ups.
The worse thing that can happen if this bug triggers is that the ftrace
self checks would find an anomaly and shut itself down.
*NOTE* My old subkey just expired. I created a new subkey: 8A87D95D
It may take a while before the key servers sync up.
Please pull the latest trace-fixes-v3.18-rc1 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-fixes-v3.18-rc1
Tag SHA1: fc028ab0bb793e19e6cd87b3348ce681f6e06d70
Head SHA1: 4fc409048d5afb1ad853f294b4262ecf2c980a49
Steven Rostedt (Red Hat) (2):
ftrace: Set ops->old_hash on modifying what an ops hooks to
ftrace: Fix checking of trampoline ftrace_ops in finding trampoline
----
kernel/trace/ftrace.c | 54 +++++++++++++++++++++++++++++++++++----------------
1 file changed, 37 insertions(+), 17 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
