ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
/*
|
|
|
|
* Code for replacing ftrace calls with jumps.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007-2008 Steven Rostedt <srostedt@redhat.com>
|
|
|
|
*
|
|
|
|
* Thanks goes to Ingo Molnar, for suggesting the idea.
|
|
|
|
* Mathieu Desnoyers, for suggesting postponing the modifications.
|
|
|
|
* Arjan van de Ven, for keeping me straight, and explaining to me
|
|
|
|
* the dangers of modifying code on the run.
|
|
|
|
*/
|
|
|
|
|
2009-10-04 18:53:29 -06:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/hardirq.h>
|
2008-08-20 10:55:07 -06:00
|
|
|
#include <linux/uaccess.h>
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
#include <linux/ftrace.h>
|
|
|
|
#include <linux/percpu.h>
|
2008-11-11 03:57:02 -07:00
|
|
|
#include <linux/sched.h>
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
|
2009-04-08 12:40:59 -06:00
|
|
|
#include <trace/syscall.h>
|
|
|
|
|
2009-02-17 15:57:30 -07:00
|
|
|
#include <asm/cacheflush.h>
|
2008-06-21 12:17:27 -06:00
|
|
|
#include <asm/ftrace.h>
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
#include <asm/nops.h>
|
2008-11-10 23:03:45 -07:00
|
|
|
#include <asm/nmi.h>
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
|
|
|
|
2008-11-10 23:03:45 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
2010-02-25 06:42:06 -07:00
|
|
|
/*
|
|
|
|
* modifying_code is set to notify NMIs that they need to use
|
|
|
|
* memory barriers when entering or exiting. But we don't want
|
|
|
|
* to burden NMIs with unnecessary memory barriers when code
|
|
|
|
* modification is not being done (which is most of the time).
|
|
|
|
*
|
|
|
|
* A mutex is already held when ftrace_arch_code_modify_prepare
|
|
|
|
* and post_process are called. No locks need to be taken here.
|
|
|
|
*
|
|
|
|
* Stop machine will make sure currently running NMIs are done
|
|
|
|
* and new NMIs will see the updated variable before we need
|
|
|
|
* to worry about NMIs doing memory barriers.
|
|
|
|
*/
|
|
|
|
static int modifying_code __read_mostly;
|
|
|
|
static DEFINE_PER_CPU(int, save_modifying_code);
|
|
|
|
|
2009-02-17 15:57:30 -07:00
|
|
|
int ftrace_arch_code_modify_prepare(void)
|
|
|
|
{
|
|
|
|
set_kernel_text_rw();
|
2010-02-25 06:42:06 -07:00
|
|
|
modifying_code = 1;
|
2009-02-17 15:57:30 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ftrace_arch_code_modify_post_process(void)
|
|
|
|
{
|
2010-02-25 06:42:06 -07:00
|
|
|
modifying_code = 0;
|
2009-02-17 15:57:30 -07:00
|
|
|
set_kernel_text_ro();
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
union ftrace_code_union {
|
2008-06-21 12:17:27 -06:00
|
|
|
char code[MCOUNT_INSN_SIZE];
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
struct {
|
|
|
|
char e8;
|
|
|
|
int offset;
|
|
|
|
} __attribute__((packed));
|
|
|
|
};
|
|
|
|
|
2008-10-23 07:33:08 -06:00
|
|
|
static int ftrace_calc_offset(long ip, long addr)
|
2008-05-12 13:20:43 -06:00
|
|
|
{
|
|
|
|
return (int)(addr - ip);
|
|
|
|
}
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
2008-11-14 17:21:19 -07:00
|
|
|
static unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
|
2008-05-12 13:20:43 -06:00
|
|
|
{
|
|
|
|
static union ftrace_code_union calc;
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
2008-05-12 13:20:43 -06:00
|
|
|
calc.e8 = 0xe8;
|
2008-06-21 12:17:27 -06:00
|
|
|
calc.offset = ftrace_calc_offset(ip + MCOUNT_INSN_SIZE, addr);
|
2008-05-12 13:20:43 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* No locking needed, this must be called via kstop_machine
|
|
|
|
* which in essence is like running on a uniprocessor machine.
|
|
|
|
*/
|
|
|
|
return calc.code;
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
}
|
|
|
|
|
2008-10-30 14:08:32 -06:00
|
|
|
/*
|
|
|
|
* Modifying code must take extra care. On an SMP machine, if
|
|
|
|
* the code being modified is also being executed on another CPU
|
|
|
|
* that CPU will have undefined results and possibly take a GPF.
|
|
|
|
* We use kstop_machine to stop other CPUS from exectuing code.
|
|
|
|
* But this does not stop NMIs from happening. We still need
|
|
|
|
* to protect against that. We separate out the modification of
|
|
|
|
* the code to take care of this.
|
|
|
|
*
|
|
|
|
* Two buffers are added: An IP buffer and a "code" buffer.
|
|
|
|
*
|
2008-10-30 22:03:22 -06:00
|
|
|
* 1) Put the instruction pointer into the IP buffer
|
2008-10-30 14:08:32 -06:00
|
|
|
* and the new code into the "code" buffer.
|
2009-03-18 02:42:57 -06:00
|
|
|
* 2) Wait for any running NMIs to finish and set a flag that says
|
|
|
|
* we are modifying code, it is done in an atomic operation.
|
|
|
|
* 3) Write the code
|
|
|
|
* 4) clear the flag.
|
|
|
|
* 5) Wait for any running NMIs to finish.
|
2008-10-30 14:08:32 -06:00
|
|
|
*
|
|
|
|
* If an NMI is executed, the first thing it does is to call
|
|
|
|
* "ftrace_nmi_enter". This will check if the flag is set to write
|
|
|
|
* and if it is, it will write what is in the IP and "code" buffers.
|
|
|
|
*
|
|
|
|
* The trick is, it does not matter if everyone is writing the same
|
|
|
|
* content to the code location. Also, if a CPU is executing code
|
|
|
|
* it is OK to write to that code location if the contents being written
|
|
|
|
* are the same as what exists.
|
|
|
|
*/
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
#define MOD_CODE_WRITE_FLAG (1 << 31) /* set when NMI should do the write */
|
2009-02-05 20:30:07 -07:00
|
|
|
static atomic_t nmi_running = ATOMIC_INIT(0);
|
2008-10-30 22:03:22 -06:00
|
|
|
static int mod_code_status; /* holds return value of text write */
|
|
|
|
static void *mod_code_ip; /* holds the IP to write to */
|
|
|
|
static void *mod_code_newcode; /* holds the text to write to the IP */
|
2008-10-30 14:08:32 -06:00
|
|
|
|
2008-10-30 22:03:22 -06:00
|
|
|
static unsigned nmi_wait_count;
|
|
|
|
static atomic_t nmi_update_count = ATOMIC_INIT(0);
|
2008-10-30 14:08:33 -06:00
|
|
|
|
|
|
|
int ftrace_arch_read_dyn_info(char *buf, int size)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
|
|
|
r = snprintf(buf, size, "%u %u",
|
|
|
|
nmi_wait_count,
|
|
|
|
atomic_read(&nmi_update_count));
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
static void clear_mod_flag(void)
|
|
|
|
{
|
|
|
|
int old = atomic_read(&nmi_running);
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
int new = old & ~MOD_CODE_WRITE_FLAG;
|
|
|
|
|
|
|
|
if (old == new)
|
|
|
|
break;
|
|
|
|
|
|
|
|
old = atomic_cmpxchg(&nmi_running, old, new);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-10-30 14:08:32 -06:00
|
|
|
static void ftrace_mod_code(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Yes, more than one CPU process can be writing to mod_code_status.
|
|
|
|
* (and the code itself)
|
|
|
|
* But if one were to fail, then they all should, and if one were
|
|
|
|
* to succeed, then they all should.
|
|
|
|
*/
|
|
|
|
mod_code_status = probe_kernel_write(mod_code_ip, mod_code_newcode,
|
|
|
|
MCOUNT_INSN_SIZE);
|
2009-02-19 11:32:57 -07:00
|
|
|
|
|
|
|
/* if we fail, then kill any new writers */
|
|
|
|
if (mod_code_status)
|
2009-03-18 02:42:57 -06:00
|
|
|
clear_mod_flag();
|
2008-10-30 14:08:32 -06:00
|
|
|
}
|
|
|
|
|
2009-02-05 23:45:16 -07:00
|
|
|
void ftrace_nmi_enter(void)
|
2008-10-30 14:08:32 -06:00
|
|
|
{
|
2010-02-25 06:42:06 -07:00
|
|
|
__get_cpu_var(save_modifying_code) = modifying_code;
|
|
|
|
|
|
|
|
if (!__get_cpu_var(save_modifying_code))
|
|
|
|
return;
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
if (atomic_inc_return(&nmi_running) & MOD_CODE_WRITE_FLAG) {
|
|
|
|
smp_rmb();
|
2008-10-30 14:08:32 -06:00
|
|
|
ftrace_mod_code();
|
2008-10-30 14:08:33 -06:00
|
|
|
atomic_inc(&nmi_update_count);
|
|
|
|
}
|
2009-03-18 02:42:57 -06:00
|
|
|
/* Must have previous changes seen before executions */
|
|
|
|
smp_mb();
|
2008-10-30 14:08:32 -06:00
|
|
|
}
|
|
|
|
|
2009-02-05 23:45:16 -07:00
|
|
|
void ftrace_nmi_exit(void)
|
2008-10-30 14:08:32 -06:00
|
|
|
{
|
2010-02-25 06:42:06 -07:00
|
|
|
if (!__get_cpu_var(save_modifying_code))
|
|
|
|
return;
|
|
|
|
|
2009-02-05 20:30:07 -07:00
|
|
|
/* Finish all executions before clearing nmi_running */
|
2009-03-18 02:42:57 -06:00
|
|
|
smp_mb();
|
2009-02-05 20:30:07 -07:00
|
|
|
atomic_dec(&nmi_running);
|
2008-10-30 14:08:32 -06:00
|
|
|
}
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
static void wait_for_nmi_and_set_mod_flag(void)
|
|
|
|
{
|
|
|
|
if (!atomic_cmpxchg(&nmi_running, 0, MOD_CODE_WRITE_FLAG))
|
|
|
|
return;
|
|
|
|
|
|
|
|
do {
|
|
|
|
cpu_relax();
|
|
|
|
} while (atomic_cmpxchg(&nmi_running, 0, MOD_CODE_WRITE_FLAG));
|
|
|
|
|
|
|
|
nmi_wait_count++;
|
|
|
|
}
|
|
|
|
|
2008-10-30 14:08:32 -06:00
|
|
|
static void wait_for_nmi(void)
|
|
|
|
{
|
2009-02-05 20:30:07 -07:00
|
|
|
if (!atomic_read(&nmi_running))
|
2009-01-26 08:28:02 -07:00
|
|
|
return;
|
2008-10-30 14:08:33 -06:00
|
|
|
|
2009-01-26 08:28:02 -07:00
|
|
|
do {
|
2008-10-30 14:08:32 -06:00
|
|
|
cpu_relax();
|
2009-02-05 20:30:07 -07:00
|
|
|
} while (atomic_read(&nmi_running));
|
2008-10-30 14:08:33 -06:00
|
|
|
|
2009-01-26 08:28:02 -07:00
|
|
|
nmi_wait_count++;
|
2008-10-30 14:08:32 -06:00
|
|
|
}
|
|
|
|
|
2009-10-28 20:46:57 -06:00
|
|
|
static inline int
|
|
|
|
within(unsigned long addr, unsigned long start, unsigned long end)
|
|
|
|
{
|
|
|
|
return addr >= start && addr < end;
|
|
|
|
}
|
|
|
|
|
2008-10-30 14:08:32 -06:00
|
|
|
static int
|
|
|
|
do_ftrace_mod_code(unsigned long ip, void *new_code)
|
|
|
|
{
|
2009-10-28 20:46:57 -06:00
|
|
|
/*
|
|
|
|
* On x86_64, kernel text mappings are mapped read-only with
|
|
|
|
* CONFIG_DEBUG_RODATA. So we use the kernel identity mapping instead
|
|
|
|
* of the kernel text mapping to modify the kernel text.
|
|
|
|
*
|
|
|
|
* For 32bit kernels, these mappings are same and we can use
|
|
|
|
* kernel identity mapping to modify code.
|
|
|
|
*/
|
|
|
|
if (within(ip, (unsigned long)_text, (unsigned long)_etext))
|
|
|
|
ip = (unsigned long)__va(__pa(ip));
|
|
|
|
|
2008-10-30 14:08:32 -06:00
|
|
|
mod_code_ip = (void *)ip;
|
|
|
|
mod_code_newcode = new_code;
|
|
|
|
|
|
|
|
/* The buffers need to be visible before we let NMIs write them */
|
|
|
|
smp_mb();
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
wait_for_nmi_and_set_mod_flag();
|
2008-10-30 14:08:32 -06:00
|
|
|
|
|
|
|
/* Make sure all running NMIs have finished before we write the code */
|
|
|
|
smp_mb();
|
|
|
|
|
|
|
|
ftrace_mod_code();
|
|
|
|
|
|
|
|
/* Make sure the write happens before clearing the bit */
|
|
|
|
smp_mb();
|
|
|
|
|
2009-03-18 02:42:57 -06:00
|
|
|
clear_mod_flag();
|
2008-10-30 14:08:32 -06:00
|
|
|
wait_for_nmi();
|
|
|
|
|
|
|
|
return mod_code_status;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-11-10 23:03:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
static unsigned char ftrace_nop[MCOUNT_INSN_SIZE];
|
|
|
|
|
2008-11-14 17:21:19 -07:00
|
|
|
static unsigned char *ftrace_nop_replace(void)
|
2008-11-10 23:03:45 -07:00
|
|
|
{
|
|
|
|
return ftrace_nop;
|
|
|
|
}
|
|
|
|
|
2008-11-14 17:21:19 -07:00
|
|
|
static int
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
|
|
|
|
unsigned char *new_code)
|
|
|
|
{
|
2008-08-20 10:55:07 -06:00
|
|
|
unsigned char replaced[MCOUNT_INSN_SIZE];
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: Due to modules and __init, code can
|
|
|
|
* disappear and change, we need to protect against faulting
|
2008-10-23 07:33:00 -06:00
|
|
|
* as well as code changing. We do this by using the
|
2008-10-23 07:33:01 -06:00
|
|
|
* probe_kernel_* functions.
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
*
|
|
|
|
* No real locking needed, this code is run through
|
2008-08-20 10:55:07 -06:00
|
|
|
* kstop_machine, or before SMP starts.
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
*/
|
2008-10-23 07:33:00 -06:00
|
|
|
|
|
|
|
/* read the text we want to modify */
|
2008-10-23 07:33:01 -06:00
|
|
|
if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
|
2008-10-23 07:32:59 -06:00
|
|
|
return -EFAULT;
|
2008-08-20 10:55:07 -06:00
|
|
|
|
2008-10-23 07:33:00 -06:00
|
|
|
/* Make sure it is what we expect it to be */
|
2008-08-20 10:55:07 -06:00
|
|
|
if (memcmp(replaced, old_code, MCOUNT_INSN_SIZE) != 0)
|
2008-10-23 07:32:59 -06:00
|
|
|
return -EINVAL;
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
2008-10-23 07:33:00 -06:00
|
|
|
/* replace the text with the new text */
|
2008-10-30 14:08:32 -06:00
|
|
|
if (do_ftrace_mod_code(ip, new_code))
|
2008-10-23 07:32:59 -06:00
|
|
|
return -EPERM;
|
2008-08-20 10:55:07 -06:00
|
|
|
|
|
|
|
sync_core();
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
|
2008-08-20 10:55:07 -06:00
|
|
|
return 0;
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
}
|
|
|
|
|
2008-11-14 17:21:19 -07:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2008-10-23 07:33:08 -06:00
|
|
|
int ftrace_update_ftrace_func(ftrace_func_t func)
|
2008-05-12 13:20:43 -06:00
|
|
|
{
|
|
|
|
unsigned long ip = (unsigned long)(&ftrace_call);
|
2008-06-21 12:17:27 -06:00
|
|
|
unsigned char old[MCOUNT_INSN_SIZE], *new;
|
2008-05-12 13:20:43 -06:00
|
|
|
int ret;
|
|
|
|
|
2008-06-21 12:17:27 -06:00
|
|
|
memcpy(old, &ftrace_call, MCOUNT_INSN_SIZE);
|
2008-05-12 13:20:43 -06:00
|
|
|
new = ftrace_call_replace(ip, (unsigned long)func);
|
|
|
|
ret = ftrace_modify_code(ip, old, new);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __init ftrace_dyn_arch_init(void *data)
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
{
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
extern const unsigned char ftrace_test_p6nop[];
|
|
|
|
extern const unsigned char ftrace_test_nop5[];
|
|
|
|
extern const unsigned char ftrace_test_jmp[];
|
|
|
|
int faulted = 0;
|
2008-05-12 13:20:43 -06:00
|
|
|
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
/*
|
|
|
|
* There is no good nop for all x86 archs.
|
|
|
|
* We will default to using the P6_NOP5, but first we
|
|
|
|
* will test to make sure that the nop will actually
|
|
|
|
* work on this CPU. If it faults, we will then
|
|
|
|
* go to a lesser efficient 5 byte nop. If that fails
|
|
|
|
* we then just use a jmp as our nop. This isn't the most
|
|
|
|
* efficient nop, but we can not use a multi part nop
|
|
|
|
* since we would then risk being preempted in the middle
|
|
|
|
* of that nop, and if we enabled tracing then, it might
|
|
|
|
* cause a system crash.
|
|
|
|
*
|
|
|
|
* TODO: check the cpuid to determine the best nop.
|
|
|
|
*/
|
|
|
|
asm volatile (
|
|
|
|
"ftrace_test_jmp:"
|
|
|
|
"jmp ftrace_test_p6nop\n"
|
2008-10-09 20:19:08 -06:00
|
|
|
"nop\n"
|
|
|
|
"nop\n"
|
|
|
|
"nop\n" /* 2 byte jmp + 3 bytes */
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
"ftrace_test_p6nop:"
|
|
|
|
P6_NOP5
|
|
|
|
"jmp 1f\n"
|
|
|
|
"ftrace_test_nop5:"
|
|
|
|
".byte 0x66,0x66,0x66,0x66,0x90\n"
|
|
|
|
"1:"
|
|
|
|
".section .fixup, \"ax\"\n"
|
|
|
|
"2: movl $1, %0\n"
|
|
|
|
" jmp ftrace_test_nop5\n"
|
|
|
|
"3: movl $2, %0\n"
|
|
|
|
" jmp 1b\n"
|
|
|
|
".previous\n"
|
|
|
|
_ASM_EXTABLE(ftrace_test_p6nop, 2b)
|
|
|
|
_ASM_EXTABLE(ftrace_test_nop5, 3b)
|
|
|
|
: "=r"(faulted) : "0" (faulted));
|
|
|
|
|
|
|
|
switch (faulted) {
|
|
|
|
case 0:
|
2009-10-04 18:53:29 -06:00
|
|
|
pr_info("converting mcount calls to 0f 1f 44 00 00\n");
|
ftrace: use a real variable for ftrace_nop in x86
Impact: avoid section mismatch warning, clean up
The dynamic ftrace determines which nop is safe to use at start up.
When it finds a safe nop for patching, it sets a pointer called ftrace_nop
to point to the code. All call sites are then patched to this nop.
Later, when tracing is turned on, this ftrace_nop variable is again used
to compare the location to make sure it is a nop before we update it to
an mcount call. If this fails just once, a warning is printed and ftrace
is disabled.
Rakib Mullick noted that the code that sets up the nop is a .init section
where as the nop itself is in the .text section. This is needed because
the nop is used later on after boot up. The problem is that the test of the
nop jumps back to the setup code and causes a "section mismatch" warning.
Rakib first recommended to convert the nop to .init.text, but as stated
above, this would fail since that text is used later.
The real solution is to extend Rabik's patch, and to make the ftrace_nop
into an array, and just save the code from the assembly to this array.
Now the section can stay as an init section, and we have a nop to use
later on.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 07:12:17 -06:00
|
|
|
memcpy(ftrace_nop, ftrace_test_p6nop, MCOUNT_INSN_SIZE);
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
break;
|
|
|
|
case 1:
|
2009-10-04 18:53:29 -06:00
|
|
|
pr_info("converting mcount calls to 66 66 66 66 90\n");
|
ftrace: use a real variable for ftrace_nop in x86
Impact: avoid section mismatch warning, clean up
The dynamic ftrace determines which nop is safe to use at start up.
When it finds a safe nop for patching, it sets a pointer called ftrace_nop
to point to the code. All call sites are then patched to this nop.
Later, when tracing is turned on, this ftrace_nop variable is again used
to compare the location to make sure it is a nop before we update it to
an mcount call. If this fails just once, a warning is printed and ftrace
is disabled.
Rakib Mullick noted that the code that sets up the nop is a .init section
where as the nop itself is in the .text section. This is needed because
the nop is used later on after boot up. The problem is that the test of the
nop jumps back to the setup code and causes a "section mismatch" warning.
Rakib first recommended to convert the nop to .init.text, but as stated
above, this would fail since that text is used later.
The real solution is to extend Rabik's patch, and to make the ftrace_nop
into an array, and just save the code from the assembly to this array.
Now the section can stay as an init section, and we have a nop to use
later on.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 07:12:17 -06:00
|
|
|
memcpy(ftrace_nop, ftrace_test_nop5, MCOUNT_INSN_SIZE);
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
break;
|
|
|
|
case 2:
|
2009-10-04 18:53:29 -06:00
|
|
|
pr_info("converting mcount calls to jmp . + 5\n");
|
ftrace: use a real variable for ftrace_nop in x86
Impact: avoid section mismatch warning, clean up
The dynamic ftrace determines which nop is safe to use at start up.
When it finds a safe nop for patching, it sets a pointer called ftrace_nop
to point to the code. All call sites are then patched to this nop.
Later, when tracing is turned on, this ftrace_nop variable is again used
to compare the location to make sure it is a nop before we update it to
an mcount call. If this fails just once, a warning is printed and ftrace
is disabled.
Rakib Mullick noted that the code that sets up the nop is a .init section
where as the nop itself is in the .text section. This is needed because
the nop is used later on after boot up. The problem is that the test of the
nop jumps back to the setup code and causes a "section mismatch" warning.
Rakib first recommended to convert the nop to .init.text, but as stated
above, this would fail since that text is used later.
The real solution is to extend Rabik's patch, and to make the ftrace_nop
into an array, and just save the code from the assembly to this array.
Now the section can stay as an init section, and we have a nop to use
later on.
Reported-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-10-24 07:12:17 -06:00
|
|
|
memcpy(ftrace_nop, ftrace_test_jmp, MCOUNT_INSN_SIZE);
|
ftrace: use only 5 byte nops for x86
Mathieu Desnoyers revealed a bug in the original code. The nop that is
used to relpace the mcount caller can be a two part nop. This runs the
risk where a process can be preempted after executing the first nop, but
before the second part of the nop.
The ftrace code calls kstop_machine to keep multiple CPUs from executing
code that is being modified, but it does not protect against a task preempting
in the middle of a two part nop.
If the above preemption happens and the tracer is enabled, after the
kstop_machine runs, all those nops will be calls to the trace function.
If the preempted process that was preempted between the two nops is executed
again, it will execute half of the call to the trace function, and this
might crash the system.
This patch instead uses what both the latest Intel and AMD spec suggests.
That is the P6_NOP5 sequence of "0x0f 0x1f 0x44 0x00 0x00".
Note, some older CPUs and QEMU might fault on this nop, so this nop
is executed with fault handling first. If it detects a fault, it will then
use the code "0x66 0x66 0x66 0x66 0x90". If that faults, it will then
default to a simple "jmp 1f; .byte 0x00 0x00 0x00; 1:". The jmp is
not optimal but will do if the first two can not be executed.
TODO: Examine the cpuid to determine the nop to use.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-08-14 16:05:05 -06:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The return code is retured via data */
|
|
|
|
*(unsigned long *)data = 0;
|
2008-05-12 13:20:43 -06:00
|
|
|
|
ftrace: dynamic enabling/disabling of function calls
This patch adds a feature to dynamically replace the ftrace code
with the jmps to allow a kernel with ftrace configured to run
as fast as it can without it configured.
The way this works, is on bootup (if ftrace is enabled), a ftrace
function is registered to record the instruction pointer of all
places that call the function.
Later, if there's still any code to patch, a kthread is awoken
(rate limited to at most once a second) that performs a stop_machine,
and replaces all the code that was called with a jmp over the call
to ftrace. It only replaces what was found the previous time. Typically
the system reaches equilibrium quickly after bootup and there's no code
patching needed at all.
e.g.
call ftrace /* 5 bytes */
is replaced with
jmp 3f /* jmp is 2 bytes and we jump 3 forward */
3:
When we want to enable ftrace for function tracing, the IP recording
is removed, and stop_machine is called again to replace all the locations
of that were recorded back to the call of ftrace. When it is disabled,
we replace the code back to the jmp.
Allocation is done by the kthread. If the ftrace recording function is
called, and we don't have any record slots available, then we simply
skip that call. Once a second a new page (if needed) is allocated for
recording new ftrace function calls. A large batch is allocated at
boot up to get most of the calls there.
Because we do this via stop_machine, we don't have to worry about another
CPU executing a ftrace call as we modify it. But we do need to worry
about NMI's so all functions that might be called via nmi must be
annotated with notrace_nmi. When this code is configured in, the NMI code
will not call notrace.
Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12 13:20:42 -06:00
|
|
|
return 0;
|
|
|
|
}
|
2008-11-10 23:03:45 -07:00
|
|
|
#endif
|
2008-11-15 22:02:06 -07:00
|
|
|
|
2008-11-25 13:07:04 -07:00
|
|
|
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
|
2008-11-15 22:02:06 -07:00
|
|
|
|
2008-11-25 22:16:24 -07:00
|
|
|
#ifdef CONFIG_DYNAMIC_FTRACE
|
|
|
|
extern void ftrace_graph_call(void);
|
|
|
|
|
|
|
|
static int ftrace_mod_jmp(unsigned long ip,
|
|
|
|
int old_offset, int new_offset)
|
|
|
|
{
|
|
|
|
unsigned char code[MCOUNT_INSN_SIZE];
|
|
|
|
|
|
|
|
if (probe_kernel_read(code, (void *)ip, MCOUNT_INSN_SIZE))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (code[0] != 0xe9 || old_offset != *(int *)(&code[1]))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
*(int *)(&code[1]) = new_offset;
|
|
|
|
|
|
|
|
if (do_ftrace_mod_code(ip, &code))
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ftrace_enable_ftrace_graph_caller(void)
|
|
|
|
{
|
|
|
|
unsigned long ip = (unsigned long)(&ftrace_graph_call);
|
|
|
|
int old_offset, new_offset;
|
|
|
|
|
|
|
|
old_offset = (unsigned long)(&ftrace_stub) - (ip + MCOUNT_INSN_SIZE);
|
|
|
|
new_offset = (unsigned long)(&ftrace_graph_caller) - (ip + MCOUNT_INSN_SIZE);
|
|
|
|
|
|
|
|
return ftrace_mod_jmp(ip, old_offset, new_offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
int ftrace_disable_ftrace_graph_caller(void)
|
|
|
|
{
|
|
|
|
unsigned long ip = (unsigned long)(&ftrace_graph_call);
|
|
|
|
int old_offset, new_offset;
|
|
|
|
|
|
|
|
old_offset = (unsigned long)(&ftrace_graph_caller) - (ip + MCOUNT_INSN_SIZE);
|
|
|
|
new_offset = (unsigned long)(&ftrace_stub) - (ip + MCOUNT_INSN_SIZE);
|
|
|
|
|
|
|
|
return ftrace_mod_jmp(ip, old_offset, new_offset);
|
|
|
|
}
|
|
|
|
|
2008-11-15 22:02:06 -07:00
|
|
|
#endif /* !CONFIG_DYNAMIC_FTRACE */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Hook the return address and push it in the stack of return addrs
|
|
|
|
* in current thread info.
|
|
|
|
*/
|
function-graph: add stack frame test
In case gcc does something funny with the stack frames, or the return
from function code, we would like to detect that.
An arch may implement passing of a variable that is unique to the
function and can be saved on entering a function and can be tested
when exiting the function. Usually the frame pointer can be used for
this purpose.
This patch also implements this for x86. Where it passes in the stack
frame of the parent function, and will test that frame on exit.
There was a case in x86_32 with optimize for size (-Os) where, for a
few functions, gcc would align the stack frame and place a copy of the
return address into it. The function graph tracer modified the copy and
not the actual return address. On return from the funtion, it did not go
to the tracer hook, but returned to the parent. This broke the function
graph tracer, because the return of the parent (where gcc did not do
this funky manipulation) returned to the location that the child function
was suppose to. This caused strange kernel crashes.
This test detected the problem and pointed out where the issue was.
This modifies the parameters of one of the functions that the arch
specific code calls, so it includes changes to arch code to accommodate
the new prototype.
Note, I notice that the parsic arch implements its own push_return_trace.
This is now a generic function and the ftrace_push_return_trace should be
used instead. This patch does not touch that code.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2009-06-18 10:45:08 -06:00
|
|
|
void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
|
|
|
|
unsigned long frame_pointer)
|
2008-11-15 22:02:06 -07:00
|
|
|
{
|
|
|
|
unsigned long old;
|
|
|
|
int faulted;
|
2008-11-25 16:57:25 -07:00
|
|
|
struct ftrace_graph_ent trace;
|
2008-11-15 22:02:06 -07:00
|
|
|
unsigned long return_hooker = (unsigned long)
|
|
|
|
&return_to_handler;
|
|
|
|
|
2008-12-05 19:43:41 -07:00
|
|
|
if (unlikely(atomic_read(¤t->tracing_graph_pause)))
|
2008-11-15 22:02:06 -07:00
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Protect against fault, even if it shouldn't
|
|
|
|
* happen. This tool is too much intrusive to
|
|
|
|
* ignore such a protection.
|
|
|
|
*/
|
|
|
|
asm volatile(
|
2009-02-10 09:53:23 -07:00
|
|
|
"1: " _ASM_MOV " (%[parent]), %[old]\n"
|
|
|
|
"2: " _ASM_MOV " %[return_hooker], (%[parent])\n"
|
2008-11-15 22:02:06 -07:00
|
|
|
" movl $0, %[faulted]\n"
|
2009-02-10 11:07:13 -07:00
|
|
|
"3:\n"
|
2008-11-15 22:02:06 -07:00
|
|
|
|
|
|
|
".section .fixup, \"ax\"\n"
|
2009-02-10 11:07:13 -07:00
|
|
|
"4: movl $1, %[faulted]\n"
|
|
|
|
" jmp 3b\n"
|
2008-11-15 22:02:06 -07:00
|
|
|
".previous\n"
|
|
|
|
|
2009-02-10 11:07:13 -07:00
|
|
|
_ASM_EXTABLE(1b, 4b)
|
|
|
|
_ASM_EXTABLE(2b, 4b)
|
2008-11-15 22:02:06 -07:00
|
|
|
|
2009-05-13 11:52:19 -06:00
|
|
|
: [old] "=&r" (old), [faulted] "=r" (faulted)
|
2009-02-10 09:53:23 -07:00
|
|
|
: [parent] "r" (parent), [return_hooker] "r" (return_hooker)
|
2008-11-15 22:02:06 -07:00
|
|
|
: "memory"
|
|
|
|
);
|
|
|
|
|
2008-12-02 21:50:02 -07:00
|
|
|
if (unlikely(faulted)) {
|
|
|
|
ftrace_graph_stop();
|
|
|
|
WARN_ON(1);
|
2008-11-15 22:02:06 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
function-graph: add stack frame test
In case gcc does something funny with the stack frames, or the return
from function code, we would like to detect that.
An arch may implement passing of a variable that is unique to the
function and can be saved on entering a function and can be tested
when exiting the function. Usually the frame pointer can be used for
this purpose.
This patch also implements this for x86. Where it passes in the stack
frame of the parent function, and will test that frame on exit.
There was a case in x86_32 with optimize for size (-Os) where, for a
few functions, gcc would align the stack frame and place a copy of the
return address into it. The function graph tracer modified the copy and
not the actual return address. On return from the funtion, it did not go
to the tracer hook, but returned to the parent. This broke the function
graph tracer, because the return of the parent (where gcc did not do
this funky manipulation) returned to the location that the child function
was suppose to. This caused strange kernel crashes.
This test detected the problem and pointed out where the issue was.
This modifies the parameters of one of the functions that the arch
specific code calls, so it includes changes to arch code to accommodate
the new prototype.
Note, I notice that the parsic arch implements its own push_return_trace.
This is now a generic function and the ftrace_push_return_trace should be
used instead. This patch does not touch that code.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2009-06-18 10:45:08 -06:00
|
|
|
if (ftrace_push_return_trace(old, self_addr, &trace.depth,
|
|
|
|
frame_pointer) == -EBUSY) {
|
2008-11-15 22:02:06 -07:00
|
|
|
*parent = old;
|
2008-11-25 16:57:25 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
trace.func = self_addr;
|
|
|
|
|
2008-12-02 21:50:05 -07:00
|
|
|
/* Only trace if the calling function expects to */
|
|
|
|
if (!ftrace_graph_entry(&trace)) {
|
|
|
|
current->curr_ret_stack--;
|
|
|
|
*parent = old;
|
|
|
|
}
|
2008-11-15 22:02:06 -07:00
|
|
|
}
|
2008-11-25 13:07:04 -07:00
|
|
|
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
|