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/5] tracing: Fixes for 7.0
Date: Thu, 19 Feb 2026 15:49:47 -0500	[thread overview]
Message-ID: <20260219204947.830172370@kernel.org> (raw)


Tracing fixes for 7.0:

- Fix possible dereference of uninitialized pointer

  When validating the persistent ring buffer on boot up, if the first
  validation fails, a reference to "head_page" is performed in the 
  error path, but it skips over the initialization of that variable.
  Move the initialization before the first validation check.

- Fix use of event length in validation of persistent ring buffer

  On boot up, the persistent ring buffer is checked to see if it is
  valid by several methods. One being to walk all the events in the
  memory location to make sure they are all valid. The length of the
  event is used to move to the next event. This length is determined
  by the data in the buffer. If that length is corrupted, it could
  possibly make the next event to check located at a bad memory location.

  Validate the length field of the event when doing the event walk.

- Fix function graph on archs that do not support use of ftrace_ops

  When an architecture defines HAVE_DYNAMIC_FTRACE_WITH_ARGS, it means
  that its function graph tracer uses the ftrace_ops of the function
  tracer to call its callbacks. This allows a single registered callback
  to be called directly instead of checking the callback's meta data's
  hash entries against the function being traced.

  For architectures that do not support this feature, it must always
  call the loop function that tests each registered callback (even if
  there's only one). The loop function tests each callback's meta data
  against its hash of functions and will call its callback if the
  function being traced is in its hash map.

  The issue was that there was no check against this and the direct
  function was being called even if the architecture didn't support it.
  This meant that if function tracing was enabled at the same time
  as a callback was registered with the function graph tracer, its
  callback would be called for every function that the function tracer
  also traced, even if the callback's meta data only wanted to be
  called back for a small subset of functions.

  Prevent the direct calling for those architectures that do not support
  it.

- Fix references to trace_event_file for hist files

  The hist files used event_file_data() to get a reference to the
  associated trace_event_file the histogram was attached to. This
  would return a pointer even if the trace_event_file is about to
  be freed (via RCU). Instead it should use the event_file_file()
  helper that returns NULL if the trace_event_file is marked to be
  freed so that no new references are added to it.

- Wake up hist poll readers when an event is being freed

  When polling on a hist file, the task is only awoken when a hist
  trigger is triggered. This means that if an event is being freed
  while there's a task waiting on its hist file, it will need to wait
  until the hist trigger occurs to wake it up and allow the freeing
  to happen. Note, the event will not be completely freed until all
  references are removed, and a hist poller keeps a reference. But
  it should still be woken when the event is being freed. 

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

Head SHA1: 9678e53179aa7e907360f5b5b275769008a69b80


Daniil Dulov (1):
      ring-buffer: Fix possible dereference of uninitialized pointer

Masami Hiramatsu (Google) (1):
      tracing: ring-buffer: Fix to check event length before using

Petr Pavlu (2):
      tracing: Fix checking of freed trace_event_file for hist files
      tracing: Wake up poll waiters for hist files when removing an event

Steven Rostedt (1):
      fgraph: Do not call handlers direct when not using ftrace_ops

----
 include/linux/ftrace.h           | 13 ++++++++++---
 include/linux/trace_events.h     |  5 +++++
 kernel/trace/fgraph.c            | 12 +++++++++++-
 kernel/trace/ring_buffer.c       |  9 +++++++--
 kernel/trace/trace_events.c      |  3 +++
 kernel/trace/trace_events_hist.c |  4 ++--
 6 files changed, 38 insertions(+), 8 deletions(-)

             reply	other threads:[~2026-02-19 20:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-19 20:49 Steven Rostedt [this message]
2026-02-19 20:49 ` [for-linus][PATCH 1/5] ring-buffer: Fix possible dereference of uninitialized pointer Steven Rostedt
2026-02-19 20:49 ` [for-linus][PATCH 2/5] tracing: ring-buffer: Fix to check event length before using Steven Rostedt
2026-02-19 20:49 ` [for-linus][PATCH 3/5] fgraph: Do not call handlers direct when not using ftrace_ops Steven Rostedt
2026-02-19 20:49 ` [for-linus][PATCH 4/5] tracing: Fix checking of freed trace_event_file for hist files Steven Rostedt
2026-02-19 20:49 ` [for-linus][PATCH 5/5] tracing: Wake up poll waiters for hist files when removing an event Steven Rostedt
  -- strict thread matches above, loose matches on Subject: below --
2026-03-22  3:09 [for-linus][PATCH 0/5] tracing: Fixes for 7.0 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=20260219204947.830172370@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