aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/Documentation/trace
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2023-05-05 13:11:02 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2023-05-05 13:11:02 -0700
commite919a3f7057b5ca918dea98826b39a38eff9bebb (patch)
tree614e799fb722519f7e0a43890ced165b4d825664 /Documentation/trace
parentMerge tag 'locking-core-2023-05-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (diff)
parentftrace: Add MODIFIED flag to show if IPMODIFY or direct was attached (diff)
downloadwireguard-linux-e919a3f7057b5ca918dea98826b39a38eff9bebb.tar.xz
wireguard-linux-e919a3f7057b5ca918dea98826b39a38eff9bebb.zip
Merge tag 'trace-v6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull more tracing updates from Steven Rostedt: - Make buffer_percent read/write. The buffer_percent file is how users can state how long to block on the tracing buffer depending on how much is in the buffer. When it hits the "buffer_percent" it will wake the task waiting on the buffer. For some reason it was set to read-only. This was not noticed because testing was done as root without SELinux, but with SELinux it will prevent even root to write to it without having CAP_DAC_OVERRIDE. - The "touched_functions" was added this merge window, but one of the reasons for adding it was not implemented. That was to show what functions were not only touched, but had either a direct trampoline attached to it, or a kprobe or live kernel patching that can "hijack" the function to run a different function. The point is to know if there's functions in the kernel that may not be behaving as the kernel code shows. This can be used for debugging. TODO: Add this information to kernel oops too. * tag 'trace-v6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ftrace: Add MODIFIED flag to show if IPMODIFY or direct was attached tracing: Fix permissions for the buffer_percent file
Diffstat (limited to 'Documentation/trace')
-rw-r--r--Documentation/trace/ftrace.rst25
1 files changed, 25 insertions, 0 deletions
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index a9c8bce4bc7b..027437b745a0 100644
--- a/Documentation/trace/ftrace.rst
+++ b/Documentation/trace/ftrace.rst
@@ -350,6 +350,19 @@ of ftrace. Here is a list of some of the key files:
an 'I' will be displayed on the same line as the function that
can be overridden.
+ If a non ftrace trampoline is attached (BPF) a 'D' will be displayed.
+ Note, normal ftrace trampolines can also be attached, but only one
+ "direct" trampoline can be attached to a given function at a time.
+
+ Some architectures can not call direct trampolines, but instead have
+ the ftrace ops function located above the function entry point. In
+ such cases an 'O' will be displayed.
+
+ If a function had either the "ip modify" or a "direct" call attached to
+ it in the past, a 'M' will be shown. This flag is never cleared. It is
+ used to know if a function was every modified by the ftrace infrastructure,
+ and can be used for debugging.
+
If the architecture supports it, it will also show what callback
is being directly called by the function. If the count is greater
than 1 it most likely will be ftrace_ops_list_func().
@@ -359,6 +372,18 @@ of ftrace. Here is a list of some of the key files:
its address will be printed as well as the function that the
trampoline calls.
+ touched_functions:
+
+ This file contains all the functions that ever had a function callback
+ to it via the ftrace infrastructure. It has the same format as
+ enabled_functions but shows all functions that have every been
+ traced.
+
+ To see any function that has every been modified by "ip modify" or a
+ direct trampoline, one can perform the following command:
+
+ grep ' M ' /sys/kernel/tracing/touched_functions
+
function_profile_enabled:
When set it will enable all functions with either the function