linux.git/kernel/trace/ftrace.c, branch v3.19-rc2

ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict

2014-11-21T19:42:10+00:00

Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
ftrace users who may modify regs->ip to change the execution
path. If two or more users modify the regs->ip on the same
function entry, one of them will be broken. So they must add
IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.

Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
flag to have notrace hash, and the ftrace_ops must have a
filter hash (so that the ftrace_ops can hook only specific
entries), because it strongly depends on the address and
must be allowed for only few selected functions.

Link: http://lkml.kernel.org/r/20141121102516.11844.27829.stgit@localhost.localdomain

Cc: Jiri Kosina 
Cc: Seth Jennings 
Cc: Petr Mladek 
Cc: Vojtech Pavlik 
Cc: Miroslav Benes 
Cc: Ingo Molnar 
Cc: Ananth N Mavinakayanahalli 
Cc: Josh Poimboeuf 
Cc: Namhyung Kim 
Signed-off-by: Masami Hiramatsu 
[ fixed up some of the comments ]
Signed-off-by: Steven Rostedt

tracing/trivial: Fix typos and make an int into a bool

2014-11-20T15:05:36+00:00

Fix up a few typos in comments and convert an int into a bool in
update_traceon_count().

Link: http://lkml.kernel.org/r/546DD445.5080108@hitachi.com

Suggested-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt

ftrace/x86/extable: Add is_ftrace_trampoline() function

2014-11-19T20:25:26+00:00

Stack traces that happen from function tracing check if the address
on the stack is a __kernel_text_address(). That is, is the address
kernel code. This calls core_kernel_text() which returns true
if the address is part of the builtin kernel code. It also calls
is_module_text_address() which returns true if the address belongs
to module code.

But what is missing is ftrace dynamically allocated trampolines.
These trampolines are allocated for individual ftrace_ops that
call the ftrace_ops callback functions directly. But if they do a
stack trace, the code checking the stack wont detect them as they
are neither core kernel code nor module address space.

Adding another field to ftrace_ops that also stores the size of
the trampoline assigned to it we can create a new function called
is_ftrace_trampoline() that returns true if the address is a
dynamically allocate ftrace trampoline. Note, it ignores trampolines
that are not dynamically allocated as they will return true with
the core_kernel_text() function.

Link: http://lkml.kernel.org/r/20141119034829.497125839@goodmis.org

Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Acked-by: Thomas Gleixner 
Signed-off-by: Steven Rostedt

tracing: Replace seq_printf by simpler equivalents

2014-11-14T02:32:19+00:00

Using seq_printf to print a simple string or a single character is a
lot more expensive than it needs to be, since seq_puts and seq_putc
exist.

These patches do

  seq_printf(m, s) -> seq_puts(m, s)
  seq_printf(m, "%s", s) -> seq_puts(m, s)
  seq_printf(m, "%c", c) -> seq_putc(m, c)

Subsequent patches will simplify further.

Link: http://lkml.kernel.org/r/1415479332-25944-2-git-send-email-linux@rasmusvillemoes.dk

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Steven Rostedt

ftrace: Have the control_ops get a trampoline

2014-11-14T00:40:56+00:00

With the new logic, if only a single user of ftrace function hooks is
used, it will get its own trampoline assigned to it.

The problem is that the control_ops is an indirect ops that perf ops
uses. What that means is that when perf registers its ops with
register_ftrace_function(), it has the CONTROL flag set and gets added
to the control list instead of the global ftrace list. The control_ops
gets added to that instead and the mcount trampoline calls the control_ops
function. The control_ops function will iterate the control list and
call the ops functions that are attached to it.

But currently the trampoline is added to the perf ops and not the
control ops, and when ftrace tries to find a trampoline hook for it,
it fails to find one and gives the following splat:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 10133 at kernel/trace/ftrace.c:2033 ftrace_get_addr_new+0x6f/0xc0()
 Modules linked in: [...]
 CPU: 0 PID: 10133 Comm: perf Tainted: P               3.18.0-rc1-test+ #388
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
  00000000000007f1 ffff8800c2643bc8 ffffffff814fca6e ffff88011ea0ed01
  0000000000000000 ffff8800c2643c08 ffffffff81041ffd 0000000000000000
  ffffffff810c388c ffffffff81a5a350 ffff880119b00000 ffffffff810001c8
 Call Trace:
  [] dump_stack+0x46/0x58
  [] warn_slowpath_common+0x81/0x9b
  [] ? ftrace_get_addr_new+0x6f/0xc0
  [] ? 0xffffffff810001c8
  [] warn_slowpath_null+0x1a/0x1c
  [] ftrace_get_addr_new+0x6f/0xc0
  [] ftrace_replace_code+0xd6/0x334
  [] ftrace_modify_all_code+0x41/0xc5
  [] arch_ftrace_update_code+0x10/0x19
  [] ftrace_run_update_code+0x21/0x42
  [] ftrace_startup_enable+0x32/0x34
  [] ftrace_startup+0x14e/0x15a
  [] register_ftrace_function+0x27/0x40
  [] perf_ftrace_event_register+0x3e/0xee
  [] perf_trace_init+0x29d/0x2a9
  [] perf_tp_event_init+0x27/0x3a
  [] perf_init_event+0x9e/0xed
  [] perf_event_alloc+0x299/0x330
  [] SYSC_perf_event_open+0x3ee/0x816
  [] ? mntput+0x2d/0x2f
  [] ? __fput+0xa7/0x1b2
  [] ? do_gettimeofday+0x22/0x3a
  [] SyS_perf_event_open+0x9/0xb
  [] system_call_fastpath+0x12/0x17
 ---[ end trace 81a53565150e4982 ]---
 Bad trampoline accounting at: ffffffff810001c8 (run_init_process+0x0/0x2d) (10000001)

Update the control_ops trampoline instead of the perf ops one.

Reported-by: lkp@01.org
Signed-off-by: Steven Rostedt

ftrace: Add more information to ftrace_bug() output

2014-11-11T17:42:13+00:00

With the introduction of the dynamic trampolines, it is useful that if
things go wrong that ftrace_bug() produces more information about what
the current state is. This can help debug issues that may arise.

Ftrace has lots of checks to make sure that the state of the system it
touchs is exactly what it expects it to be. When it detects an abnormality
it calls ftrace_bug() and disables itself to prevent any further damage.
It is crucial that ftrace_bug() produces sufficient information that
can be used to debug the situation.

Cc: Benjamin Herrenschmidt 
Acked-by: Borislav Petkov 
Tested-by: Masami Hiramatsu 
Tested-by: Jiri Kosina 
Signed-off-by: Steven Rostedt

ftrace/x86: Allow !CONFIG_PREEMPT dynamic ops to use allocated trampolines

2014-11-11T17:41:52+00:00

When the static ftrace_ops (like function tracer) enables tracing, and it
is the only callback that is referencing a function, a trampoline is
dynamically allocated to the function that calls the callback directly
instead of calling a loop function that iterates over all the registered
ftrace ops (if more than one ops is registered).

But when it comes to dynamically allocated ftrace_ops, where they may be
freed, on a CONFIG_PREEMPT kernel there's no way to know when it is safe
to free the trampoline. If a task was preempted while executing on the
trampoline, there's currently no way to know when it will be off that
trampoline.

But this is not true when it comes to !CONFIG_PREEMPT. The current method
of calling schedule_on_each_cpu() will force tasks off the trampoline,
becaues they can not schedule while on it (kernel preemption is not
configured). That means it is safe to free a dynamically allocated
ftrace ops trampoline when CONFIG_PREEMPT is not configured.

Cc: H. Peter Anvin 
Cc: Paul E. McKenney 
Acked-by: Borislav Petkov 
Tested-by: Masami Hiramatsu 
Tested-by: Jiri Kosina 
Signed-off-by: Steven Rostedt

ftrace/x86: Show trampoline call function in enabled_functions

2014-10-31T16:22:54+00:00

The file /sys/kernel/debug/tracing/eneabled_functions is used to debug
ftrace function hooks. Add to the output what function is being called
by the trampoline if the arch supports it.

Add support for this feature in x86_64.

Cc: H. Peter Anvin 
Tested-by: Masami Hiramatsu 
Tested-by: Jiri Kosina 
Signed-off-by: Steven Rostedt

ftrace/x86: Add dynamic allocated trampoline for ftrace_ops

2014-10-31T16:22:35+00:00

The current method of handling multiple function callbacks is to register
a list function callback that calls all the other callbacks based on
their hash tables and compare it to the function that the callback was
called on. But this is very inefficient.

For example, if you are tracing all functions in the kernel and then
add a kprobe to a function such that the kprobe uses ftrace, the
mcount trampoline will switch from calling the function trace callback
to calling the list callback that will iterate over all registered
ftrace_ops (in this case, the function tracer and the kprobes callback).
That means for every function being traced it checks the hash of the
ftrace_ops for function tracing and kprobes, even though the kprobes
is only set at a single function. The kprobes ftrace_ops is checked
for every function being traced!

Instead of calling the list function for functions that are only being
traced by a single callback, we can call a dynamically allocated
trampoline that calls the callback directly. The function graph tracer
already uses a direct call trampoline when it is being traced by itself
but it is not dynamically allocated. It's trampoline is static in the
kernel core. The infrastructure that called the function graph trampoline
can also be used to call a dynamically allocated one.

For now, only ftrace_ops that are not dynamically allocated can have
a trampoline. That is, users such as function tracer or stack tracer.
kprobes and perf allocate their ftrace_ops, and until there's a safe
way to free the trampoline, it can not be used. The dynamically allocated
ftrace_ops may, although, use the trampoline if the kernel is not
compiled with CONFIG_PREEMPT. But that will come later.

Tested-by: Masami Hiramatsu 
Tested-by: Jiri Kosina 
Signed-off-by: Steven Rostedt

ftrace: Fix checking of trampoline ftrace_ops in finding trampoline

2014-10-24T20:53:11+00:00

When modifying code, ftrace has several checks to make sure things
are being done correctly. One of them is to make sure any code it
modifies is exactly what it expects it to be before it modifies it.
In order to do so with the new trampoline logic, it must be able
to find out what trampoline a function is hooked to in order to
see if the code that hooks to it is what's expected.

The logic to find the trampoline from a record (accounting descriptor
for a function that is hooked) needs to only look at the "old_hash"
of an ops that is being modified. The old_hash is the list of function
an ops is hooked to before its update. Since a record would only be
pointing to an ops that is being modified if it was already hooked
before.

Currently, it can pick a modified ops based on its new functions it
will be hooked to, and this picks the wrong trampoline and causes
the check to fail, disabling ftrace.

Signed-off-by: Steven Rostedt 

ftrace: squash into ordering of ops for modification