Commit b1e00ffaf91c for kernel

commit b1e00ffaf91c41eb752a1c200295c9ab7abfae1d
Merge: 2beb1b31a12b d80e12156f1f
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sun Sep 6 14:21:24 2026 -0700

    Merge tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace

    Pull tracing fixes from Steven Rostedt:

     - 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.

       An 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.

    * tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
      ring-buffer: Use a macro for static buffer bits
      tracing: Fix comment in tracing_buffers_splice_read()
      ring-buffer: Prevent truncation of nr_pages / nr_subbufs
      ring-buffer: Cap static ring buffer nr_pages
      tracing: Fix subbuf resize races with trace_pipe_raw readers
      tracing: Fix to avoid creating trace instances with duplicate names
      ring-buffer: Add checking nr_subbufs to persistent ring buffer validation
      ring-buffer: Allow splice reads on static buffers
      tracing: Take trace_array reference when opening options file
      ftrace: Synchronize the initialization of ftrace_ops
      ftrace: Take trace_array reference before accessing its ftrace_ops
      tracing: Have show_event_filters/triggers files take trace array ref