Skip to content

tracing: Fixes for v7.0

Steven Rostedt lkml stable 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest6 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/6fgraph: Fix thresh_return clear per-task notracekernel/trace/trace_functions_graph.c+3 -20 replies
2/6fgraph: Fix thresh_return nosleeptime double-adjustkernel/trace/trace_functions_graph.c+10 -40 replies
3/6tracing: Fix syscall events activation by ensuring refcount hits zerokernel/trace/trace_events.c+37 -150 replies
4/6ftrace: Disable preemption in the tracepoint callbacks handling filtered pidskernel/trace/ftrace.c+2 -00 replies
5/6tracing: Disable preemption in the tracepoint callbacks handling filtered pidskernel/trace/trace_events.c+2 -00 replies
6/6tracing: Fix WARN_ON in tracing_buffers_mmap_closeinclude/linux/ring_buffer.h kernel/trace/ring_buffer.c kernel/trace/trace.c+35 -00 replies

Reviews trailers per patch

2 of 6 patches have a Reviewed-by or Acked-by.

PatchMasami Hiramatsu (Google)[email protected]
1/6A-b
2/6A-b
3/6
4/6
5/6
6/6T-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [for-linus][PATCH 0/6] tracing: Fixes for v7.0

tracing fixes for v7.0:

- Fix thresh_return of function graph tracer

The update to store data on the shadow stack removed the abuse of using the task recursion word as a way to keep track of what functions to ignore. The trace_graph_return() was updated to handle this, but when function_graph tracer is using a threshold (only trace functions that took longer than a specified time), it uses trace_graph_thresh_return() instead. This function was still incorrectly using the task struct recursion word causing the function graph tracer to permanently set all functions to "notrace"

- Fix thresh_return nosleep accounting

When the calltime was moved to the shadow stack storage instead of being on the fgraph descriptor, the calculations for the amount of sleep time was updated. The calculation was done in the trace_graph_thresh_return() function, which also called the trace_graph_return(), which did the calculation again, causing the time to be doubled.

Remove the call to trace_graph_return() as what it needed to do wasn't that much, and just do the work in trace_graph_thresh_return().

- Fix syscall trace event activation on boot up

The syscall trace events are pseudo events attached to the raw_syscall tracepoints. When the first syscall event is enabled, it enables the raw_syscall tracepoint and doesn't need to do anything when a second syscall event is also enabled.

When events are enabled via the kernel command line, syscall events are partially enabled as the enabling is called before rcu_init. After rcu_init, they are disabled and re-enabled so that they can be fully enabled. The problem happened is that this "disable-enable" is done one at a time. If more than one syscall event is specified on the command line, by disabling them one at a time never makes the counter go to zero, and the raw_syscall is not disabled and enabled.

Instead, disable all events and re-enabled them all, as that will ensure the raw_syscall event is also disabled and re-enabled.

- Disable preemption in ftrace pid filtering

The ftrace pid filtering attaches to the fork and exit tracepoints to add or remove pids that should be traced. They access variables protected by RCU (preemption disabed). Now that tracepoint callbacks are called with preemption, this protection needs to be added explicitly, and not depend on the functions being called with preemption disabled.

- Disable preemption in event pid filtering

The event pid filtering needs the same preemption disabling guards as ftrace pid filtering.

- Fix accounting of the memory mapped ring buffer on fork

Memory mapping the ftrace ring buffer sets the vm_flags to DONTCOPY. But this does not prevent the application from calling madvise(MADVISE_DOFORK). This causes the mapping to be copied on fork. After the first tasks exits, the mapping is considered unmapped by everyone. But when he second task exits, the counter goes below zero and triggers a WARN_ON.

Since nothing prevents two separate tasks from mmapping the ftrace ring buffer (although weird the two will mess each other up), there's no reason to stop the memory from being copied on fork.

Update the vm_operations to have an ".open" handler to update the accounting and let the ring buffer know someone else has it mapped.

git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/fixes

Head SHA1: e39bb9e02b68942f8e9359d2a3efe7d37ae6be0e

Huiwen He (1):
tracing: Fix syscall events activation by ensuring refcount hits zero

Masami Hiramatsu (Google) (1):
tracing: Disable preemption in the tracepoint callbacks handling filtered pids

Qing Wang (1):
tracing: Fix WARN_ON in tracing_buffers_mmap_close

Shengming Hu (2):
fgraph: Fix thresh_return clear per-task notrace
fgraph: Fix thresh_return nosleeptime double-adjust

Steven Rostedt (1):
ftrace: Disable preemption in the tracepoint callbacks handling filtered pids

----

 include/linux/ring_buffer.h          |  1 +
 kernel/trace/ftrace.c                |  2 ++
 kernel/trace/ring_buffer.c           | 21 ++++++++++++++
 kernel/trace/trace.c                 | 13 +++++++++
 kernel/trace/trace_events.c          | 54 ++++++++++++++++++++++++++----------
 kernel/trace/trace_functions_graph.c | 19 +++++++++----
 6 files changed, 89 insertions(+), 21 deletions(-)