public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [for-linus][PATCH 0/6] tracing: Fixes for v7.0
Date: Wed, 04 Mar 2026 17:03:19 -0500	[thread overview]
Message-ID: <20260304220319.218314827@kernel.org> (raw)


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(-)

             reply	other threads:[~2026-03-04 22:03 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04 22:03 Steven Rostedt [this message]
2026-03-04 22:03 ` [for-linus][PATCH 1/6] fgraph: Fix thresh_return clear per-task notrace Steven Rostedt
2026-03-04 22:03 ` [for-linus][PATCH 2/6] fgraph: Fix thresh_return nosleeptime double-adjust Steven Rostedt
2026-03-04 22:03 ` [for-linus][PATCH 3/6] tracing: Fix syscall events activation by ensuring refcount hits zero Steven Rostedt
2026-03-04 22:03 ` [for-linus][PATCH 4/6] ftrace: Disable preemption in the tracepoint callbacks handling filtered pids Steven Rostedt
2026-03-04 22:03 ` [for-linus][PATCH 5/6] tracing: " Steven Rostedt
2026-03-04 22:03 ` [for-linus][PATCH 6/6] tracing: Fix WARN_ON in tracing_buffers_mmap_close Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260304220319.218314827@kernel.org \
    --to=rostedt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox