Pull scheduler fix from Borislav Petkov:

 - Make sure a delayed sched entity's runtime stats are updated at the
   right time so that it receives the proper lag compensation

* tag 'sched_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Update time before requeueing delayed entities

Pull perf fixes from Borislav Petkov:

 - Prevent the use of exited events as group leaders

 - Avoid use-after-free of an event's group leader by promoting detached
   sibling events to standalone entities and correct related accounting
   and state transitions

* tag 'perf_urgent_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/core: Fix group leader use-after-free after sibling detach
  perf: Reject exited events as group leaders

Pull vfs fixes from Christian Brauner:

 - Don't warn when a mount is completed from another user namespace.

   fsopen() records the caller's user namespace in fc->user_ns and
   hands back an ordinary file descriptor. The task that calls
   fsconfig(FSCONFIG_CMD_CREATE) doesn't have to be the one that
   created the context, and mount_capable() lets it through as long
   as the caller has CAP_SYS_ADMIN over fc->user_ns, which anyone in
   an ancestor namespace does. So fc->user_ns != current_user_ns()
   is something an unprivileged user can arrange.

   Both overlayfs and binfmt_misc WARN_ON() that. Overlayfs already
   has the same check as a plain error return in ovl_parse_param().

   Drop the WARN_ON() and just refuse. Add selftests for both cases.

 - Reject pid allocations through dead ancestor pid namespaces.

   Require PIDNS_ADDING in every namespace that will receive the pid
   before publishing any of them. That preserves the invariant that
   free_pid() never decrements pid_allocated in a namespace whose
   child_reaper is no longer live. The existing ENOMEM behavior is
   unchanged.

* tag 'vfs-7.2-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
  pid: reject allocations through dead ancestor pid namespaces
  selftests/filesystems: test completing a context from another user namespace
  binfmt_misc: don't warn when the mount is completed from another user namespace
  ovl: don't warn when the mount is completed from another user namespace

In order to compute the right lag, it is required to update time to 'now'.
Without this, the delayed entity might appear younger than it really is and
receive less compensation for having waited.

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

The following sequence may leads race between event_define_fields()
and update_event_fields():

 CPU0 (loads module A)                      CPU1 (loads module B)
 ===============================            ===============================
 load_module(A)                             load_module(B)
   notifier_call_chain                        notifier_call_chain
     trace_module_notify                        trace_module_notify
       mutex_lock(&event_mutex)                   trace_event_update_all()
         trace_module_add_events(A)                 down_write(&trace_event_sem)
            __register_event(call_A)
              __add_event_to_tracers(call_A)
                event_define_fields(call_A)
                  for each f:                         list_for_each_entry(field,
                    list_add(&f->link,                                    &class->fields, link)
                             &class->fields)            field = class->fields->next;

Where access to the class->fields is not protected by the event_mutex in
trace_event_update_all().

This produces the following panic:
   Unable to handle kernel access ... at virtual address 0000000000000018
   pc : update_event_fields+0xf8/0x368
   Call trace:
    update_event_fields+0xf8/0x368
    trace_event_update_all+0x7c/0x2b4
    trace_module_notify+0x4c/0x1dc
    notifier_call_chain+0x84/0x168
    blocking_notifier_call_chain_robust+0x64/0xd4
    load_module+0x10c8/0x123c
    __arm64_sys_finit_module+0x230/0x31c

Fix by taking event_mutex in trace_event_update_all() before
trace_event_sem.

Cc: stable@vger.kernel.org
Fixes: b3bc8547d3be ("tracing: Have TRACE_DEFINE_ENUM affect trace event types as well")
Link: https://patch.msgid.link/2e5730d2-c631-da41-3a3a-ae35bb4895f3@allwinnertech.com
Signed-off-by: Michael Wu <michael@allwinnertech.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

A module-only event filter such as ":mod:foo" is cached with a NULL
event_mod->match when foo has not been loaded. If a later write tries to
remove a specific match from the same module, remove_cache_mod() passes
the NULL cached match to strcmp(), causing a NULL pointer dereference.

The issue can be reproduced from userspace:

  echo ':mod:trace_events_kunit_missing' > /sys/kernel/tracing/set_event
  echo '!foo_bar:mod:trace_events_kunit_missing' >> /sys/kernel/tracing/set_event

The second write must be a concatenation (">>") to not include O_TRUNC as
that would cause ftrace_clear_events() to clear the cached modules lines.

The crash was reproduced on x86_64 QEMU while KUnit workers contended on
the event tracing path:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor read access in kernel mode
  RIP: 0010:strcmp+0x10/0x30
  Call Trace:
   __ftrace_set_clr_event_nolock+0x373/0x4a0
   ftrace_set_clr_event+0xf0/0x180
   ftrace_event_write+0xdf/0x110
   vfs_write+0xf6/0x440
   ksys_write+0x68/0xe0
   do_syscall_64+0xf9/0x540
   entry_SYSCALL_64_after_hwframe+0x77/0x7f

Check event_mod->match before comparing it, consistent with the existing
NULL checks for the cached system and event fields. The mismatched removal
continues to return -EINVAL; a broad cached module filter is removed with
"!:mod:<module>".

Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260811173902.1927376-2-sh_def@163.com
Fixes: b355247df104 ("tracing: Cache \":mod:\" events for modules not loaded yet")
Reported-by: syzbot+4d3143c8e28f6266c636@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/lkml/6a7a6b7f.9c11d2ce.289b96.00f8.GAE@google.com/
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

alloc_pid() checks PIDNS_ADDING only on the leaf pid namespace before
making a new struct pid visible in every ancestor namespace. That is
insufficient when an unborn descendant pid namespace outlives an
ancestor whose init task has already exited. The descendant can still be
initialized later through setns(), and the new pid is then published
into the dead ancestor as well.

Keep the existing ENOMEM behavior, but require PIDNS_ADDING to be set in
every namespace that will receive the new pid before publishing any of
them. This preserves the invariant that free_pid() never decrements
pid_allocated in a namespace whose child_reaper is no longer live.

Fixes: a3bdc23ba8ea ("pid_namespace: allow opening pid_for_children before init was created")
Signed-off-by: Jérémy Jean <Jeremy.Jean@oss.cyber.gouv.fr>
Reviewed-by: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

Pull tracing fixes from Steven Rostedt:

 - Fix use-after-free in eventfs_remove_rec()

   The freeing of the eventfs_inode children used list_for_each_entry()
   where the child is freed via srcu, but there's still a chance that it
   gets freed. It should be using list_for_each_entry_safe().

 - Fix eventfs_inode SRCU use of list in freeing

   The iterator uses an SRCU protected list walk on the eventfs inodes.
   The eventfs inode uses its "list" field in a union with the RCU list
   head. When the inode gets added to the SRCU list it immediately
   corrupts the list pointer and can cause an issue with the iterator.
   Move the RCU list head to be shared with the children list head which
   allows the iterator to check the parent inode if is freed before
   referencing the child. Have the iterator check the parent "is_freed"
   field and break out if it is set. Also add memory barriers to make
   sure the ordering is correct.

 - Fix various RCU synchronization issues with direct_functions

   Updates to direct_functions have some missing RCU protection and
   synchronization. Restructure the code a bit to make sure updates to
   the direct_functions are protected.

 - Remove an unneeded comma from a scope_guard()

   There's a spurious comma in a scope_guard(). Remove it.

 - Fix race in per CPU buffer swap in the ring buffer

   When a per CPU buffer swap happens, it must make sure that it doesn't
   occur while a writer is active. Instead it returns an -EBUSY. But
   there's a small race window when a writer moves from one sub-buffer
   to the next that it resets the "committing" counter. If a swap
   happens at that moment, the buffer used for the commit of an event
   will not match the buffer the event is actually on. Instead of using
   the "committing" counter, use the recursive detection counter that
   does not get reset when the writer crosses sub-buffers.

 - Fix off-by-one in ftrace_free_mem()

   The function ftrace_free_mem() gets an "end_ptr" as a parameter that
   is exclusive to the rang to be freed. But its value is used to search
   for the records that expects an inclusive value. Subtract one from
   the parameter to convert it to an inclusive range.

 - Disable resizing of the ring buffer for persistent buffers

   Resizing the persistent buffer has undefined behavior. Prevent it
   from being resized.

 - Disable changing ring buffer subbuf order when resizing is disabled

   The ring buffer subbuffer order can not be changed during resizing.
   Use that instead of just checking if the buffer is mapped as mapped
   buffers also have resizing disabled.

 - Initialize subbuf_order of reader pages when they are created

   In rb_allocate_cpu_buffer() the bpage->order is not updated to the
   current subbuf_order leaving it as zero. This value is used when the
   page is freed.

 - Fix test_ringbuffer() to test for ERR_PTR before calling
   kthread_stop()

   The rb_threads[] array is assigned the output of kthread_run_on_cpu()
   which could return an ERR_PTR. At the end of the test, all threads in
   the array are cleaned up by kthread_stop() passing in the value in
   the array if it isn't zero. But if the array contains an ERR_PTR,
   kthread_stop() will not be able to handle it properly.

* tag 'trace-v7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
  ring-buffer: Fix crash passing ERR_PTR to kthread_stop()
  ring-buffer: Initialise reader page order in rb_allocate_cpu_buffer()
  ring-buffer: Prevent subbuf order change when resizing is disabled
  ring-buffer: Prevent resizing of persistent ring buffer
  ftrace: Fix off-by-one fentry site disable in ftrace_free_mem()
  ring-buffer: Use current_context for safe per-CPU buffer swap
  ftrace: Drop extra comma in trace_buffered_event_enable
  ftrace: Protect direct_functions in update_ftrace_direct_mod
  ftrace: Protect direct_functions in update_ftrace_direct_del
  ftrace: Protect direct_functions in ftrace_find_rec_direct
  eventfs: Use children field for rcu head and add memory barriers
  eventfs: Fix use-after-free in eventfs_remove_rec()

In test_ringbuffer()'s out_free cleanup loop, the check
`!rb_threads[cpu]` only catches NULL entries and misses entries that
hold an ERR_PTR.

rb_threads[] is static, so unassigned slots are NULL. But when
kthread_run_on_cpu() fails for a cpu, it stores ERR_PTR(-ENOMEM) (or
-EINTR) in rb_threads[cpu] before the creation loop jumps to out_free.
That entry is non-NULL, so the old `!ptr` check does not break, and the
cleanup proceeds to call kthread_stop() on the ERR_PTR. kthread_stop()
then dereferences the bogus pointer, crashing the kernel during the
late_initcall self-test.

crash logs:
  BUG: kernel NULL pointer dereference, address: 000000000000001c
  Oops: 0002 [#1] SMP NOPTI
  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy)
  RIP: 0010:kthread_stop+0x2e/0x220
  RBX: fffffffffffffff4
  CR2: 000000000000001c
  Call Trace:
   <TASK>
   test_ringbuffer+0x1ec/0x650
   do_one_initcall+0x6c/0x2c0
   kernel_init_freeable+0x21d/0x420
   kernel_init+0x15/0x1c0
   ret_from_fork+0x21b/0x320
   </TASK>
  Kernel panic - not syncing: Fatal exception

Cc: stable@vger.kernel.org
Fixes: 64ed3a049e3e ("ring-buffer: make use of the helper function kthread_run_on_cpu()")
Link: https://patch.msgid.link/20260807154145.2846521-2-sh_def@163.com
Signed-off-by: Hui Su <sh_def@163.com>
Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

In rb_allocate_cpu_buffer(), bpage->order was omitted, leaving it as 0.
This is an issue for a ring-buffer with subbufs bigger than PAGE_SIZE if
when freed: free_buffer_page() relies on this value. Align the value
with the actual allocation size (buffer::subbuf_order).

Cc: stable@vger.kernel.org
Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page")
Link: https://patch.msgid.link/20260806211306.3704194-4-vdonnefort@google.com
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>