Paul,
I found the bug that was causing large modules to fail in setting
up dynamic ftrace. It wound up being a simple math error. To calculate
the offset in the TOC, I had used an OR, but the bottom half was
a signed extended short, and it should have been an addition.
The fix is in my tree below, as well as posted here.
-- Steve
The following patch is in:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git
branch: ppc/ftrace
Steven Rostedt (1):
ftrace, powerpc64: fix math to calculate offset in TOC
----
arch/powerpc/kernel/ftrace.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
---------------------------
commit 60e611577d908119bb515ead908a46b025a4c9f9
Author: Steven Rostedt <srost...@redhat.com>
Date: Sat Feb 7 22:00:26 2009 -0800
ftrace, powerpc64: fix math to calculate offset in TOC
Impact: fix dynamic ftrace with large modules in PPC64
The math to calculate the offset into the TOC that is taken from reading
the trampoline is incorrect. The bottom half of the offset is a signed
extended short. The current code was using an OR to create the offset
when it should have been using an addition.
Signed-off-by: Steven Rostedt <srost...@redhat.com>
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 88c641d..4112175 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -191,8 +191,9 @@ __ftrace_make_nop(struct module *mod,
return -EINVAL;
}
- offset = (unsigned)((unsigned short)jmp[0]) << 16 |
- (unsigned)((unsigned short)jmp[1]);
+ /* The bottom half is signed extended */
+ offset = ((unsigned)((unsigned short)jmp[0]) << 16) +
+ (int)((short)jmp[1]);
pr_debug(" %x ", offset);
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
