Skip to content

tracing: Fixes for 6.11

Steven Rostedt bpf lkml stable 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest6 patches 0 repliesNew 1 of 6 applied

Patches in v1 1 of 6 applied

#Subject and filesSizeRepliesApplied
1/6tracing: fgraph: Fix to add new fgraph_ops to array after ftrace_startup_subops()kernel/trace/fgraph.c+18 -130 repliesApplied
2/6tracing: Fix memory leak in fgraph storage selftestkernel/trace/trace_selftest.c+18 -50 replies
3/6tracing/timerlat: Only clear timer if a kthread existskernel/trace/trace_osnoise.c+4 -10 replies
4/6tracing/osnoise: Use a cpumask to know what threads are kthreadskernel/trace/trace_osnoise.c+15 -30 replies
5/6tracing: Avoid possible softlockup in tracing_iter_reset()kernel/trace/trace.c+2 -00 replies
6/6eventfs: Use list_del_rcu() for SRCU protected list variablefs/tracefs/event_inode.c+1 -10 replies

Reviews trailers per patch

None of the 6 patches has a Reviewed-by or Acked-by.

PatchChi Zhiling
1/6
2/6
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 6.11

Tracing fixes for 6.11:

- Fix adding a new fgraph callback after function graph tracing has already started.

If the new caller does not initialize its hash before registering the fgraph_ops, it can cause a NULL pointer dereference. Fix this by adding a new parameter to ftrace_graph_enable_direct() passing in the newly added gops directly and not rely on using the fgraph_array[], as entries in the fgraph_array[] must be initialized. Assign the new gops to the fgraph_array[] after it goes through ftrace_startup_subops() as that will properly initialize the gops->ops and initialize its hashes.

- Fix a memory leak in fgraph storage memory test.

If the "multiple fgraph storage on a function" boot up selftest fails in the registering of the function graph tracer, it will not free the memory it allocated for the filter. Break the loop up into two where it allocates the filters first and then registers the functions where any errors will do the appropriate clean ups.

- Only clear the timerlat timers if it has an associated kthread.

In the rtla tool that uses timerlat, if it was killed just as it was shutting down, the signals can free the kthread and the timer. But the closing of the timerlat files could cause the hrtimer_cancel() to be called on the already freed timer. As the kthread variable is is set to NULL when the kthreads are stopped and the timers are freed it can be used to know not to call hrtimer_cancel() on the timer if the kthread variable is NULL.

Note, this code requires more design changes to fix properly, but this is a easy workaround that can be backported to stable.

- Use a cpumask to keep track of osnoise/timerlat kthreads

The timerlat tracer can use user space threads for its analysis. With the killing of the rtla tool, the kernel can get confused between if it is using a user space thread to analyze or one of its own kernel threads. When this confusion happens, kthread_stop() can be called on a user space thread and bad things happen. As the kernel threads are per-cpu, a bitmask can be used to know when a kernel thread is used or when a user space thread is used.

- Add cond_resched() to the tracing_iter_reset() loop.

The latency tracers keep writing to the ring buffer without resetting when it issues a new "start" event (like interrupts being disabled). When reading the buffer with an iterator, the tracing_iter_reset() sets its pointer to that start event by walking through all the events in the buffer until it gets to the time stamp of the start event. In the case of a very large buffer, the loop that looks for the start event has been reported taking a very long time with a non preempt kernel that it can trigger a soft lock up warning. Add a cond_resched() into that loop to make sure that doesn't happen.

- Use list_del_rcu() for eventfs ei->list variable

It was reported that running loops of creating and deleting kprobe events could cause a crash due to the eventfs list iteration hitting a LIST_POISON variable. This is because the list is protected by SRCU but when an item is deleted from the list, it was using list_del() which poisons the "next" pointer. This is what list_del_rcu() was to prevent.

Masami Hiramatsu (Google) (2):
tracing: fgraph: Fix to add new fgraph_ops to array after ftrace_startup_subops()
tracing: Fix memory leak in fgraph storage selftest

Steven Rostedt (3):
tracing/timerlat: Only clear timer if a kthread exists tracing/osnoise: Use a cpumask to know what threads are kthreads
eventfs: Use list_del_rcu() for SRCU protected list variable

Zheng Yejian (1):
tracing: Avoid possible softlockup in tracing_iter_reset()

----

 fs/tracefs/event_inode.c      |  2 +-
 kernel/trace/fgraph.c         | 31 ++++++++++++++++++-------------
 kernel/trace/trace.c          |  2 ++
 kernel/trace/trace_osnoise.c  | 23 +++++++++++++++++++----
 kernel/trace/trace_selftest.c | 23 ++++++++++++++++++-----
 5 files changed, 58 insertions(+), 23 deletions(-)