mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Vincent Donnefort <vdonnefort@google.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [GIT PULL] tracing: Fixes for 7.3
Date: Sun, 6 Sep 2026 16:03:16 -0400	[thread overview]
Message-ID: <20260906160316.5aed43e3@robin> (raw)


Linus,

tracing fixes for v7.3:

- Fix several tracefs files that did not take the trace_array reference

  A trace instance can be created and destroyed in the tracefs "instances"
  directory via mkdir and rmdir respectively. The instance is represented by
  a trace_array descriptor. Most tracefs files pass the trace_array as the
  private data of the inode to the open/read/write functions. Since there is
  no locking between the time a task opens a file and the deletion of the
  instance (and the freeing of the trace_array), each open needs to get a
  reference to the trace_array and each close must remove it. A instance
  can't be removed if there's any reference taken on its trace_array. The
  open function uses trace_array_get() that takes a lock (preventing removal
  of instances) and iterates the list of all existing trace_arrays and if it
  finds a match, it takes the reference and releases the lock. If it doesn't
  find a match, it causes the open to return -ENODEV.

  There were some added files that did not take the trace_array reference
  on open that needed to be fixed. Sashiko also correctly pointed out that
  there were some files that took an address of an field or element of the
  trace_array which had a pointer back to the trace_array to take its
  reference on open. But this leaves a slight race between referencing this
  element to get the trace_array as the element itself could be freed. To
  solve this, some helper functions were created to look for trace_arrays
  with this field or element in the search so that the element did not have
  to be dereferenced before the trace_array's reference was taken.

- Add a lock around ftrace_ops initialization

  When a ftrace_ops is first used by ftrace, some internal initialization is
  performed on the ops. But if multiple tasks were calling functions that
  did this initialization, it could race and perform doing the
  initialization more than once, corrupting the internal data. Add a lock in
  the initialization code to prevent this from happening.

- Fix splice reads on mmapped buffers

  The logic in the ring buffer splice code for mmapped buffers is supposed
  to do a copy of the memory as the mapped buffers can't be given to splice.
  But there was an if statement within the copy code that would return a -1
  if a request for a full page was done and it wasn't a partial read. This
  is because this logic was written before mmapped buffers existed and this
  case didn't make sense at the time. For mmapped buffers it makes perfect
  sense and by returning early can drop a lot of pages unnecessarily.

- Have the persistent ring buffer validation check nr_subbufs

  Sashiko reported that the validation code was relying on the saved
  nr_subbufs to match the calculated nr_pages + 1 and if they were off, that
  the code could cause corruption. Sashiko is correct, and the saved
  nr_subbufs should be validated before assuming it is correct.

- Do not allow more than one instance with the same name on cmdline

  If an admin were to add more than one trace instances with the same name
  they all would be created, but only the first one would be accessible via
  tracefs. This used to not be allowed but some restructuring of code has
  since made it possible.

- Fix the race between subbuf resize and trace_pipe_raw readers

  If a task was reading trace_pipe_raw while another task was changing the
  ring buffer subbuf size, it could crash the reader. The trace_pipe_raw
  readers do get their own copy of the page from the buffer, but the code
  needs some restructuring to not have the resize of the subbuffers cause
  issues.

- Cap the size of the mapped (static) ring buffer nr_pages

  The meta data used for ring buffer mapped buffers is 32 bit in size. A
  normal ring buffer could (in theory) have more than 4 billion pages.
  But this is not allowed by mapped buffers, so enforce it.


Please pull the latest trace-v7.3-rc1 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace-v7.3-rc1

Tag SHA1: d878c05d090306c6cfb75b77ed73aad53677d59e
Head SHA1: d80e12156f1fd490adf29a8d28489725a3ac817a


Masami Hiramatsu (Google) (1):
      tracing: Fix to avoid creating trace instances with duplicate names

Steven Rostedt (7):
      tracing: Have show_event_filters/triggers files take trace array ref
      ftrace: Take trace_array reference before accessing its ftrace_ops
      ftrace: Synchronize the initialization of ftrace_ops
      tracing: Take trace_array reference when opening options file
      ring-buffer: Add checking nr_subbufs to persistent ring buffer validation
      tracing: Fix comment in tracing_buffers_splice_read()
      ring-buffer: Use a macro for static buffer bits

Vincent Donnefort (4):
      ring-buffer: Allow splice reads on static buffers
      tracing: Fix subbuf resize races with trace_pipe_raw readers
      ring-buffer: Cap static ring buffer nr_pages
      ring-buffer: Prevent truncation of nr_pages / nr_subbufs

----
 include/linux/ftrace.h               |   5 +-
 include/linux/ring_buffer.h          |   5 +-
 kernel/trace/ftrace.c                |  70 ++++++----
 kernel/trace/ring_buffer.c           | 239 +++++++++++++++++++++++------------
 kernel/trace/ring_buffer_benchmark.c |   6 +-
 kernel/trace/trace.c                 | 171 ++++++++++++++++---------
 kernel/trace/trace.h                 |  14 +-
 kernel/trace/trace_events.c          |  28 +++-
 kernel/trace/trace_functions.c       |   2 +-
 kernel/trace/trace_stack.c           |   2 +-
 10 files changed, 357 insertions(+), 185 deletions(-)
---------------------------

             reply	other threads:[~2026-09-06 20:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06 20:03 Steven Rostedt [this message]
2026-09-06 21:50 ` pr-tracker-bot
  -- strict thread matches above, loose matches on Subject: below --
2026-08-30  1:15 Steven Rostedt
2026-08-30 17:23 ` pr-tracker-bot

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=20260906160316.5aed43e3@robin \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vdonnefort@google.com \
    /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

all inboxes | Powered by JetHome®