| Message ID | 20081120221149.GA2470@blackbean.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote: > Ingo and Steven, > > Here's an updated version of the arch/arm changes for dynamic ftrace > based on top of your latest tip/master. Excuse me if I'm rather confused, but... When ftrace for ARM was originally merged, neither linux-arm-kernel nor myself were copied with the patches. Now, I'm being sent updates to code that I've no understanding of and haven't seen before. I mean, yes, it's nice to be copied with patches which are relevent. It would've been even nicer to have been copied with the patches adding ftrace in the first place, so people knew something about it and were aware of the changes. It seems to me like there's been a total breakdown of communication when ftrace was initially merged... So, questions: has ftrace actually been tested on ARM at all? Has it been reviewed? Which ARM platforms has it been tried on? How stable is it? How has it been implemented on ARM? Does it rely on any CPU specific behaviour? Looking at the git history, ftrace was merged via Ingo, so I assume that Ingo has some understanding of this code. So, for the time being if these are urgent updates, I suggest that updates go through Ingo's tree rather than mine. And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2 which we've been working towards supporting. What about SMP? ARM is a SMP capable architecture now, and I see no locking in there - what I do see is static data with pointers to it being returned to other code... Yuck.
On Fri, 21 Nov 2008, Russell King - ARM Linux wrote: > On Thu, Nov 20, 2008 at 02:11:49PM -0800, Jim Radford wrote: > > Ingo and Steven, > > > > Here's an updated version of the arch/arm changes for dynamic ftrace > > based on top of your latest tip/master. > > Excuse me if I'm rather confused, but... > > When ftrace for ARM was originally merged, neither linux-arm-kernel > nor myself were copied with the patches. Now, I'm being sent updates > to code that I've no understanding of and haven't seen before. > > I mean, yes, it's nice to be copied with patches which are relevent. > It would've been even nicer to have been copied with the patches adding > ftrace in the first place, so people knew something about it and were > aware of the changes. > > It seems to me like there's been a total breakdown of communication > when ftrace was initially merged... Yes I totally agree that in the beginning there was a breakdown of communication. I myself just learned of the ARM port. > > So, questions: has ftrace actually been tested on ARM at all? Has it > been reviewed? Which ARM platforms has it been tried on? How stable > is it? How has it been implemented on ARM? Does it rely on any CPU > specific behaviour? > > Looking at the git history, ftrace was merged via Ingo, so I assume > that Ingo has some understanding of this code. So, for the time being > if these are urgent updates, I suggest that updates go through Ingo's > tree rather than mine. I would suggest that they at least get an ACK from you. The original code should have too. > > And looking at arch/arm/kernel/ftrace.c, it's incompatible with Thumb2 > which we've been working towards supporting. What about SMP? ARM is > a SMP capable architecture now, and I see no locking in there - what > I do see is static data with pointers to it being returned to other > code... Yuck. Some of this code will be redesigned in 29. But as for the locking, this code is run under kstop_machine. Which means that even on SMP architectures, this acts like a UP box. Some of the code can be run outside of kstop_machine, but it is protected by locks in the module code. I'll take a look at the ftrace.c arm code and see if there's any problems with it. I wrote the x86 version as well as the coming PowerPC port. Thanks, -- Steve
Index: linux-2.6/arch/arm/Kconfig =================================================================== --- linux-2.6.orig/arch/arm/Kconfig +++ linux-2.6/arch/arm/Kconfig @@ -16,7 +16,9 @@ config ARM select HAVE_ARCH_KGDB select HAVE_KPROBES if (!XIP_KERNEL) select HAVE_KRETPROBES if (HAVE_KPROBES) - select HAVE_FUNCTION_TRACER if (!XIP_KERNEL) + select HAVE_FTRACE_MCOUNT_RECORD + select HAVE_DYNAMIC_FTRACE if (!XIP_KERNEL) + select HAVE_FUNCTION_TRACER select HAVE_GENERIC_DMA_COHERENT help The ARM series is a line of low-power-consumption RISC chip designs Index: linux-2.6/arch/arm/include/asm/ftrace.h =================================================================== --- linux-2.6.orig/arch/arm/include/asm/ftrace.h +++ linux-2.6/arch/arm/include/asm/ftrace.h @@ -7,6 +7,19 @@ #ifndef __ASSEMBLY__ extern void mcount(void); + +static inline unsigned long ftrace_call_adjust(unsigned long addr) +{ + return addr; +} + +#ifdef CONFIG_DYNAMIC_FTRACE + +struct dyn_arch_ftrace { + /* No extra data needed for x86 */ +}; + +#endif /* CONFIG_DYNAMIC_FTRACE */ #endif #endif Index: linux-2.6/arch/arm/kernel/entry-common.S =================================================================== --- linux-2.6.orig/arch/arm/kernel/entry-common.S +++ linux-2.6/arch/arm/kernel/entry-common.S @@ -104,14 +104,7 @@ ENDPROC(ret_from_fork) #ifdef CONFIG_FUNCTION_TRACER #ifdef CONFIG_DYNAMIC_FTRACE ENTRY(mcount) - stmdb sp!, {r0-r3, lr} - mov r0, lr - sub r0, r0, #MCOUNT_INSN_SIZE - - .globl mcount_call -mcount_call: - bl ftrace_stub - ldmia sp!, {r0-r3, pc} + mov pc, lr ENTRY(ftrace_caller) stmdb sp!, {r0-r3, lr} Index: linux-2.6/arch/arm/kernel/ftrace.c =================================================================== --- linux-2.6.orig/arch/arm/kernel/ftrace.c +++ linux-2.6/arch/arm/kernel/ftrace.c @@ -23,13 +23,13 @@ static unsigned long bl_insn; static const unsigned long NOP = 0xe1a00000; /* mov r0, r0 */ -unsigned char *ftrace_nop_replace(void) +static unsigned char *ftrace_nop_replace(void) { return (char *)&NOP; } /* construct a branch (BL) instruction to addr */ -unsigned char *ftrace_call_replace(unsigned long pc, unsigned long addr) +static unsigned char *ftrace_call_replace(unsigned long pc, unsigned long addr) { long offset; @@ -46,7 +46,7 @@ unsigned char *ftrace_call_replace(unsig return (unsigned char *)&bl_insn; } -int ftrace_modify_code(unsigned long pc, unsigned char *old_code, +static int ftrace_modify_code(unsigned long pc, unsigned char *old_code, unsigned char *new_code) { unsigned long err = 0, replaced = 0, old, new; @@ -82,22 +82,46 @@ int ftrace_modify_code(unsigned long pc, return err; } +int ftrace_make_nop(struct module *mod, + struct dyn_ftrace *rec, unsigned long addr) +{ + unsigned char *new, *old; + unsigned long ip = rec->ip; + + old = ftrace_call_replace(ip, addr); + new = ftrace_nop_replace(); + + return ftrace_modify_code(rec->ip, old, new); +} + +int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr) +{ + unsigned char *new, *old; + unsigned long ip = rec->ip; + + old = ftrace_nop_replace(); + new = ftrace_call_replace(ip, addr); + + return ftrace_modify_code(rec->ip, old, new); +} + int ftrace_update_ftrace_func(ftrace_func_t func) { + unsigned long ip = (unsigned long)(&ftrace_call); + unsigned char old[MCOUNT_INSN_SIZE], *new; int ret; - unsigned long pc, old; - unsigned char *new; - pc = (unsigned long)&ftrace_call; - memcpy(&old, &ftrace_call, MCOUNT_INSN_SIZE); - new = ftrace_call_replace(pc, (unsigned long)func); - ret = ftrace_modify_code(pc, (unsigned char *)&old, new); + memcpy(old, &ftrace_call, sizeof(old)); + new = ftrace_call_replace(ip, (unsigned long)func); + ret = ftrace_modify_code(ip, (unsigned char *)&old, new); + return ret; } /* run from kstop_machine */ int __init ftrace_dyn_arch_init(void *data) { - ftrace_mcount_set(data); + /* The return code is retured via data */ + *(unsigned long *)data = 0; return 0; }
Ingo and Steven, Here's an updated version of the arch/arm changes for dynamic ftrace based on top of your latest tip/master. -Jim --- From: Jim Radford <radford@galvanix.com> Subject: ftrace: enable dynamic ftrace for arm Update to the latest api, syncing functions with the x86 versions.