From: Jiri Kosina <jkos...@suse.cz> The only reliable way for function redirection through ftrace_ops (when modifying pt_regs->rip in the handler) is fentry.
The alternative -- mcount -- is problematic in several ways. Namely the caller's function prologue (that has already been executed by the time mcount callsite has been reached) is not known to the callee, and can be completely incompatible to the calee, resulting in a havoc on return from the function. fentry doesn't suffer from this, as it's located at the very beginning of the function, even before prologue has been executed, and therefore callee is the owner of both function prologue and epilogue. Fixing mcount to properly fix everything up would be non-trivial, and Steven is not in favor of doing that. Both kGraft and upstream kernel (patch to be submitted) should error out when this unsupported and non-working configuration is detected. According to Michael Matz, the -mfentry gcc option is x86 specific. Other architectures insert the respective profile calls before the prologue by default. Signed-off-by: Jiri Kosina <jkos...@suse.cz> Signed-off-by: Jiri Slaby <jsl...@suse.cz> Cc: Michael Matz <m...@suse.de> Cc: Steven Rostedt <rost...@goodmis.org> Cc: Frederic Weisbecker <fweis...@gmail.com> Cc: Ingo Molnar <mi...@redhat.com> --- arch/x86/include/asm/kgraft.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/include/asm/kgraft.h b/arch/x86/include/asm/kgraft.h index 5e40ba1a0753..6fc57a85d12c 100644 --- a/arch/x86/include/asm/kgraft.h +++ b/arch/x86/include/asm/kgraft.h @@ -17,6 +17,10 @@ #ifndef ASM_KGR_H #define ASM_KGR_H +#ifndef CC_USING_FENTRY +#error Your compiler has to support -mfentry for kGraft to work on x86 +#endif + #include <asm/ptrace.h> static inline void kgr_set_regs_ip(struct pt_regs *regs, unsigned long ip) -- 2.0.0 -- 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/
