aboutsummaryrefslogtreecommitdiffstats
path: root/kernel
AgeCommit message (Collapse)AuthorFilesLines
29 hoursMerge tag 'sched-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds2-14/+21
Pull scheduler fixes from Ingo Molnar: - Fix __sched_setscheduler() class change race causing lost reschedules, exposed by recent RCU changes (K Prateek Nayak) - Fix s64 multiplication overflow in place_entity()'s vlag scaling code that can corrupt an entity's placement (Hui Su) * tag 'sched-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Avoid overflow in place_entity() sched/core: Call wakeup_preempt() for queued tasks during class change
30 hoursMerge tag 'perf-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-19/+14
Pull perf events fixes from Ingo Molnar: - Fix x86 Intel uncore driver bug on Diamond Rapids CPUs that erroneously always-cleared the invert bit (Guixiong Wei) - Fix accounting bug in the perf mlock 'gift' code causing unrelated RLIMIT_MEMLOCK functionality to fail (Lorenzo Stoakes) - Fix perf_pmu_migrate_context() bug leaving events behind during CPU hot-unplug (Haris Okanovic) - Update cgroup time when rotating multiplexed events, to fix time_running & scaled counts accounting bug (Antoine Huret) * tag 'perf-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Update cgroup time when rotating multiplexed events perf: Fix perf_pmu_migrate_context() leaving events behind perf: Track the perf mlock gift separately perf/x86/intel/uncore: Fix DMR CXL CM invert filter
30 hoursMerge tag 'locking-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds1-23/+28
Pull locking fixes from Ingo Molnar: - Fix FUT_OFF_MMSHARED futex hashing bug that can cause missed wakeups or spurious wakeups on futex-waiting tasks (Jann Horn) - Fix lockdep context tracking bug in the deferred hrtimer rearming entry code, which causes a lockdep chain leak that will eventually turn lockdep off (Mikhail Gavrilov) * tag 'locking-urgent-2026-10-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: entry: Account the deferred hrtimer rearm as hardirq context for lockdep futex: Fix mm reuse handling for FUT_OFF_MMSHARED
3 daysMerge tag 'printk-for-7.3-hotfix' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linuxLinus Torvalds3-2/+12
Pull printk fixes from Petr Mladek: - Switch NBCON consoles to the emergency mode in emergency_restart() to see messages even in this shutdown code path - Postpone the start of printk kthreads after smp_init(). It prevents boot stalls on some HW - Typo fix in a previous hot-fix patch * tag 'printk-for-7.3-hotfix' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: printk: Postpone kthread startup printk: fix kernel-doc name for nbcon_write_context_is_braille nbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart()
3 daysMerge tag 'trace-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-traceLinus Torvalds7-50/+83
Pull tracing fixes from Steven Rostedt: - Fix NULL dereference when copying histogram field variable If event_hist_trigger_parse() creates an action that uses one of pseudo fields for its keys, the hist_data field element will have a NULL for its field member. When looking to match that key, the lookup uses key_field->field->name which will dereference a NULL pointer. Instead use the helper function that handles such cases: expr_field_str(). - Take the trace_types_lock when dropping the buffer_meta reference The tracing_buffer_meta_open() error return drops the trace_array reference with __trace_array_put() instead of trace_array_put() where the former doesn't take the lock and the latter does. - Fix NULL pointer dereference when reading per_cpu/cpuN/buffer_meta These files are created for every possible CPU. But it only contains data for CPUs that have come online. If one is read for a CPU that hasn't come online yet, it triggers a NULL pointer dereference. Have reading of CPUs that have not come on line yet return -ENODEV. - Fix an out-of-bounds shift in the log2 histogram modifier Histograms can take a log2 modifier to have the buckets defined by log2 increments. If a shift is greater than ULONG_MAX or above 2^63, the key falls into a lower order bucket. Use order_base_2() instead of "ilog2(n - 1) + 1" to have all overflowed keys go into the top bucket. - Fix the persistent ring buffer rb_meta_subbuf_idx() accounting The algorithm for finding the index of a sub-buffer in a persistent ring buffer buffer did not take into account the meta data at the beginning of the buffer causing the wrong index to be returned. As rb_subbufs_from_meta() does the proper accounting to find the first sub-buffer, use that function instead of repeating the logic (incorrectly) and make the calculations based off of that. - Fix the symbol name checks for the remote buffer code The remote ring buffer has a build time check to make sure its not using any code that will not be in the hypervisor. For various architectures, there has been false positive reports from this checker. Fix them. - Fix false warning in ring_buffer_map_get_reader() There is a WARN_ON() after rb_get_reader_page() if no reader is returned. But there are legitimate cases where this can happen. Remove the WARN_ON() and also a check that covers one of the legitimate cases that tries to exit out early. There's no need for the check if it just simply allows the return of NULL from rb_get_reader_page(). - Fix the ignored return value from resize_buffer_duplicate_size() Some clean up of the code in tracing_snapshot_write() removed checking the return value of resize_buffer_duplicate_size() and if that failed it would not be detected. - Fix the histogram timestamps for buffered events The histogram timestamps are taken from the events that are recorded. It currently reads ring_buffer_event_time_stamp() but if the event is buffered it does not read it properly. Use tracing_event_time_stamp() which handles both buffered and normal events. - Do not initialize tracefs if tracing is disabled at boot If tracing fails to allocate or some other error is detected, tracing_disabled is set. Do not initialize tracefs in this case as it may expect data to be initialized but is not. - Free eventfs inode after an RCU grace period Currently eventfs_inodes are freed after a SRCU grace period as the iterations in the code use SRCU. There are locations that the inode may still be accessed from the VFS that uses RCU which does not have the same synchronization as SRCU. Add an RCU wait before free eventfs inodes. - Do not fail persistent and remote buffers under memory pressure As persistent and remote buffers have their own pre-allocated memory, there's no reason to check how much memory is available before created them. By checking the memory pressure, these buffers may fail to be created even though their memory is already present. - Account for subbuffer size when checking how much memory is available Before allocating a ring buffer, the size is checked against the current memory pressure of the system. But it assumes every sub-buffer is of page size. This is no longer the case. Use the actual sub-buffer size when calculating how much memory will be used. - Reject non-stack fields for synthetic stacktrace fields Stack traces are special fields and the checks currently do not do enough to make sure that the fields being processed as stack traces are indeed stack traces. Update the logic to properly detect what is or is not a stack trace. - Fix a crash in print_graph_function_event() When a tracer does not define static or default flags the tr->current_trace_flags is set to NULL. If the ring buffer is not cleared when switching tracers, the previous tracers events could be read. The function_graph entries will dereference the tr->current_trace_flags and cause a crash. Set the tr->current_trace_flags to a empty set of flags to prevent it from being NULL. - Separate tracing filter predicate count from allocation The amount allocated for the predicate program is the number of predicates defined plus two for adding "true" and "false" at the end. The nr_preds is incremented by two to accommodate the booleans but is then used as the limit check for number of predicates. This is incorrect as it is now two higher than what is expected. Use a separate variable for the size of the predicate array. - Fix the filter operator stack check The operator stack increments the pointer and then writes the content onto the stack. The check for overflow compared the current pointer to see if it was greater than the stack size before doing so. This is an off by 2 error as the write will be at the size - 1 and the compare is done before the increment. Adjust the check accordingly. * tag 'trace-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: Check operator stack capacity before pushing tracing: Keep the predicate limit separate from program capacity tracing: Fix crash in print_graph_function_event() tracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fields ring-buffer: Use subbuf_order in available memory estimation ring-buffer: Skip si_mem_available() for persistent and remote buffers eventfs: Free the eventfs_inode after an rcu grace period too tracing: Do not initialize tracefs work if tracing is disabled tracing: Fix hist trigger timestamps for buffered events tracing: Fix ignored return value of resize_buffer_duplicate_size() ring-buffer: Fix false warning in ring_buffer_map_get_reader() tracing: Fix simple_ring_buffer undef check on sparc64 tracing: Fix simple_ring_buffer undef check on parisc tracing: Fix empty symbol names in simple_ring_buffer undef check ring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx() tracing: Fix the shift out of bounds in the log2 histogram modifier ring-buffer: Do not show buffer_meta for CPUs without a buffer tracing: Take trace_types_lock when dropping the buffer_meta reference tracing: Fix NULL dereference when copying keys for a field variable
3 daysMerge tag 'probes-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-traceLinus Torvalds1-2/+1
Pull probes fix from Masami Hiramatsu: - error out if BTF is required but unavailable Fix to return an error instead of NULL if BTF is not available when user specify '$args*' meta fetch argument for probe events. * tag 'probes-fixes-v7.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: tracing: probes: error if BTF is required but unavailable
3 daysMerge branch 'for-7.3-hotfix' into for-linusPetr Mladek3-2/+12
3 daysprintk: Postpone kthread startupJohn Ogness1-1/+1
There have been various bug reports related to SMP systems hanging on boot. The reports vary but seem to have some overlap with regard to missed IPI's during SMP setup. The reports also show that reverting NBCON console usage allows the bugs to disappear. The NBCON kthreads for console printing are started very early during boot using early_initcall(). Since these kthreads are asynchronously enabling/disabling interrupts during early boot, they may be interfering with early SMP setup on some hardware platforms. Starting the console printing kthreads later has shown to avoid the hanging on systems that could previously reproduce the issue. Postpone kthread starting until after all arch initcalls have completed. Reported-by: Derek Barbosa <debarbos@redhat.com> Closes: https://lore.kernel.org/linux-rt-users/arPmYPbFLf2EldIl@debarbos-thinkpadt14gen5.rmtusma.csb Fixes: 76f258bf3f2a ("printk: nbcon: Introduce printer kthreads") Signed-off-by: John Ogness <john.ogness@linutronix.de> Tested-by: Derek Barbosa <debarbos@redhat.com> Link: https://patch.msgid.link/20261016085441.857695-1-john.ogness@linutronix.de Signed-off-by: Petr Mladek <pmladek@suse.com>
3 daysMerge tag 'vfs-7.3-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfsLinus Torvalds4-11/+24
Pull vfs fixes from Christian Brauner: - Fix a range of use-after-frees during rcu pathwalk caused by non-rcu frees. Whatever ->permission(), ->d_revalidate(), ->get_link(), ->d_hash() and ->d_compare() read in rcu mode has to be freed after a grace period. umount(2) hides most of it because namespace_unlock() waits for one, but a chdir() out of a lazily unmounted directory or the close() of the last file on it drops the last reference without. * ext4_get_link() reads the sbi and the extent status counters for a symlink stored in a data block. Both are freed after a grace period now. * The unicode map of casefolded ext4, f2fs and tmpfs was freed under generic_ci_d_hash() and generic_ci_d_compare(). * ntfs3 with nocase freed its sbi and mount options under its dentry hash and compare. A remount freed the old options right away too. * eventfs freed an eventfs_inode after an SRCU grace period only while tracefs_d_revalidate() reads it under rcu_read_lock(). * afs and 9p are only saved by the grace period their private bdi gets in bdi_unregister(). They stop depending on it. * create_ipc_ns() leaked the mqueue mount and its superblock on a late failure. A long-term mount needs kern_unmount(). - Don't let idle threads pin the initramfs. The idle threads of the secondary cpus are forked from PID 1 with a private copy of its fs_struct, aren't on the task list so pivot_root() never moves them and never exit. So the initramfs stayed pinned forever on every machine with more than one cpu, 70 to 150 MB in the reports. They share init_fs now like init_task does. - A mount that copy_tree() leaves out can't take over a lock. copy_tree() drops mounts of mount namespace files from the copies it makes for unshare(CLONE_NEWNS) and propagation without looking at MNT_LOCKED. So root in a user namespace could bind a child's /proc/<pid>/ns/mnt beneath a locked cover, let it take the lock over, unshare(CLONE_NEWNS) and read the file. copy_tree() refuses with EPERM now and the move beneath a locked mount is refused up front. - Revert "namei: don't reveal overmounted entries in refwalk" from the rc7 fixes. The bug class is bigger than that patch. - namei: lookup_fast_for_open() checked ->d_inode while traverse_mounts() checks the type in d_flags, which is set second, so a refwalk racing the instantiation could fail an O_CREAT open with ENOENT. Use d_is_negative() in both places. - Drop the smp_mb()s in mntput_no_expire_slowpath() and do_umount() that mnt_get_count()'s own barrier made redundant. - fsnotify: a mark added while fsnotify_destroy_marks() walks the connector could be missed and the connector detached, so an fdinfo read called igrab(NULL). New marks are refused during teardown. - pipe: a failed second fasync enable on an O_RDWR FIFO removed the existing reader entry and cleared FASYNC while the writer entry stayed, a use-after-free in send_sigio() later. - watch_queue: post_one_notification() could see nr_notes before the note pool behind it and dereference a NULL array. An unprivileged user can trigger that with a key watch. Publish nr_notes last. - pid_namespace: zap_pid_ns_processes() waits without bound for a tracer outside the namespace to reap its zombies and neither wait was freezable, so every suspend attempt failed. - exit: is_child_subreaper and has_child_subreaper shared a word with other bitfields written without a common lock, so racing prctl()s lost a bit. They are separate bools now. - autofs: a notification write that failed on a pipe the daemon had already replaced put the superblock into catatonic mode again and closed the replacement. Only do that for the current pipe. - ovl: reject a lowerdir ending with an unescaped backslash with EINVAL instead of a confusing ENOENT later. - ocfs2/dlm: take dlm_reco_state_lock when the debugfs state file walks the recovery participant list. - samples/pidfd: fix the userprogs typo that kept pidfd-metadata from being built. * tag 'vfs-7.3-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (24 commits) Revert "namei: don't reveal overmounted entries in refwalk" selftests/filesystems: test that a mntns file can't take over a lock fs: let idle threads share init_fs namespace: a mount that copy_tree() leaves out can't take over a lock namei: test for a negative dentry the way traverse_mounts() does fs: pass flags to copy_fs() ovl: reject lowerdir ending with unescaped backslash fsnotify: prevent mark additions during connector teardown pid_namespace: make zap_pid_ns_processes() freezable fs: drop the smp_mb()s that mnt_get_count() made redundant autofs: ignore notification errors from a replaced pipe ntfs3: free replaced mount options after a grace period ntfs3: free the sbi after a grace period unicode: free the map after a grace period ipc: drop the mqueue mount with kern_unmount() on setup failure eventfs: free the eventfs_inode after an rcu grace period too 9p: free the session after a grace period watch_queue: Fix note pool publication race in watch_queue_set_size() afs: free the super info after a grace period pipe: preserve existing fasync readers on writer setup failure ...
4 daysperf: Update cgroup time when rotating multiplexed eventsAntoine Huret1-0/+1
Since commit bd2756811766 ("perf: Rewrite core context handling"), perf_rotate_context() only updates the context time before scheduling out the flexible events. It no longer updates the cgroup time, which ctx_sched_out() used to do. Cgroup events take their times from the per-cpu cgroup clock, so between two cgroup switches the rotations see a frozen clock. The events rotated out lose the running time they accumulated, and the next update, usually a read, credits the whole interval to the events that happen to be on the PMU at that moment. As a result, the time_running of multiplexed cgroup events is wrong, and so are their scaled counts, as long as no other cgroup runs on the CPU, e.g. a busy job alone on its CPUs. Counting cycles over one second of a busy loop in a cgroup gives from half to several times the max frequency of the CPU. Update the cgroup time before rotating the CPU context, as was done before the rewrite. Fixes: bd2756811766 ("perf: Rewrite core context handling") Closes: https://lore.kernel.org/r/PR3PR07MB69223331EED5BEBE150375B7849C2@PR3PR07MB6922.eurprd07.prod.outlook.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Antoine Huret <antoine.huret@bull.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015-perf-cgroup-rotation-time-v1-1-93e177dfee5d@bull.com
4 daysperf: Fix perf_pmu_migrate_context() leaving events behindHaris Okanovic1-13/+7
__perf_pmu_remove() walks the group leaders of a CPU and PMU with perf_event_groups_for_cpu_pmu(), removing each one as it goes. perf_remove_from_context() takes the leader out of the groups rbtree, after which rb_next() on that node returns NULL, prematurely ending the walk. Other groups stay behind in the source context. On CPU hotplug, they are then torn down with the dying CPU. They keep running until teardown, while the PMU's interrupt and migrated events are on a new CPU, which drivers rely on never happening. Walk ctx->event_list instead and pick out the PMU's events by their pmu_ctx. Fixes: bd2756811766 ("perf: Rewrite core context handling") Signed-off-by: Haris Okanovic <harisokn@amazon.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20261013185603.1347265-2-harisokn@amazon.com
4 daysperf: Track the perf mlock gift separatelyLorenzo Stoakes (ARM)1-6/+6
The locked_vm field in struct user_struct was originally introduced by commit 789f90fcf6b0 ("perf_counter: per user mlock gift") to provide an mlock-like budget for perf measured against mm->pinned_vm (since 2011). perf grants each user a 'gift' of perf_event_mlock_kb * online CPUs of buffer pages which is charged to user->locked_vm without any RLIMIT_MEMLOCK check. Only pages beyond the gift are checked against RLIMIT_MEMLOCK, per-mm, via mm->pinned_vm, which makes it different from the standard mlock() check, which is per-mm and made against RLIMIT_MEMLOCK. However, since this was introduced, a number of other components have utilised this field where a shared resource needed to be limited against RLIMIT_MEMLOCK. The other users are currently MSG_ZEROCOPY, io_uring, AF_XDP, iommufd, s390 KVM zPCI and most recently, secretmem in commit 97d34aa65c29 ("mm/secretmem: properly account locked pages"). This field is shared between all of these, but because the gift is not checked against RLIMIT_MEMLOCK, user->locked_vm alone can exceed it - 16 CPUs * 516 KiB is already more than the default 8 MiB - after which every other user of the field fails unconditionally. This was reported by a user who saw secretmem failing while running a simultaneous perf record. Resolve the issue by simply giving perf its own field separate from the rest. BPF used user->locked_vm up until commit 80ee81e0403c ("bpf: Eliminate rlimit-based memory accounting infra for bpf maps") which landed in 5.11. Thus also eliminate the now-defunct ifdef for CONFIG_BPF_SYSCALL for user->locked_vm. This issue exists between all of the components which use user->locked_vm and perf, however secretmem is the first user who has caused a report over many years and has been backported, so target the fix at that. Fixes: 97d34aa65c29 ("mm/secretmem: properly account locked pages") Closes: https://lore.kernel.org/20261002175651.811343-1-ameer.hamza@truenas.com Reported-by: Ameer Hamza <ameer.hamza@truenas.com> Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261003-perf-locked-vm-fix-v1-1-d214dcaf0d76@kernel.org
4 dayssched/fair: Avoid overflow in place_entity()Hui Su1-4/+12
place_entity() inflates an entity's virtual lag with lag * (load + weight) / load Commit 4823725d9d1d ("sched/fair: Increase weight bits for avg_vruntime") replaced the scaled-down weights used in this calculation with avg_vruntime_weight(), removing the arithmetic headroom provided by scale_load_down(). The multiplication can overflow s64 before the division even when the final quotient is representable. A task's hierarchical effective weight can be as small as 2 after avg_vruntime_weight() scaling under group scheduling, while entity_lag() bounds |vlag| by calc_delta_fair(cfs_rq_max_slice(cfs_rq) + TICK_NSEC, se) For example, with HZ=1000, NICE_0_LOAD=1048576, and the minimum scaled hierarchical weight scale_load(2)=2048, this bound is 891289600. With 114 maximum-weight entities, the runqueue load is 10361604096. The intermediate product is: 891289600 * (10361604096 + 2) = 9235189971864780800 > S64_MAX The signed overflow corrupts the entity's placement. Rewrite lag * (load + weight) / load as lag + lag * weight / load The two expressions are equivalent, but the latter avoids multiplying the virtual lag by the total runqueue weight. entity_lag() bounds vlag against the entity's effective weight, so the remaining lag * weight product stays bounded. rescale_entity() preserves this scale across h_load changes and already relies on the same product when rescaling vlag. Keep the original zero-load warning semantics by multiplying lag by weight after replacing the divisor with one. Fixes: 4823725d9d1d ("sched/fair: Increase weight bits for avg_vruntime") Signed-off-by: Hui Su <sh_def@163.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260928124754.1692077-1-sh_def@163.com
4 daystracing: Check operator stack capacity before pushingTaeyang Lee1-1/+1
predicate_parse() uses the first operator stack entry before processing any opening parentheses. A push then increments top before writing. The existing check still permits that write when top already points to the last allocated entry, which can access beyond the operator stack. Reject the push when top reaches the last allocated entry. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELO9L0I9kg5CpC@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
4 daystracing: Keep the predicate limit separate from program capacityTaeyang Lee1-4/+3
predicate_parse() adds two to nr_preds to reserve the terminal TRUE and FALSE entries. It also uses that increased value as the limit for parsed predicates. If the initial count is smaller than the number actually parsed, the program can fill the allocation and subsequent accesses can go past its end. Keep nr_preds as the predicate limit and use a separate value for the allocation size. This leaves space for both terminal entries and a zeroed entry when parsing stops at the limit. Cc: stable@vger.kernel.org Fixes: 39f7c41c908b ("tracing/filters: Enable filtering a cpumask field by another cpumask") Link: https://patch.msgid.link/atELCd1XjKVhrkFL@Taeyangs-MacBook-Pro.local Signed-off-by: Taeyang Lee <0wn@theori.io> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
4 daystracing: Fix crash in print_graph_function_event()Hao Ge1-2/+18
tracing_set_tracer() assigns the flags of the newly selected tracer with: tr->current_trace_flags = t->flags ? : t->tracer->flags; If the new tracer defines neither static flags nor default flags, like hwlat, irqsoff or wakeup, add_tracer() has no per instance flags copy for it, and both operands are NULL, so tr->current_trace_flags ends up being NULL as well. The ring buffer is not cleared when switching tracers: it is reset inside tracer_init(), after current_trace_flags was already assigned. If the buffer still holds function_graph entries of the previous tracer, printing one of them dereferences the NULL pointer. This was hit by cat trace during an ftrace stress test: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode RIP: 0010:print_graph_function_event+0xe/0x20 Call Trace: s_show+0x4d/0x110 seq_read_iter+0x2d4/0x490 seq_read+0x130/0x170 vfs_read+0xb5/0x370 ksys_read+0x6d/0xe0 do_syscall_64+0xbc/0x450 The snapshot buffer is not reset at all, so this can be reproduced without a race: echo function_graph > /sys/kernel/tracing/current_tracer echo 1 > /sys/kernel/tracing/snapshot echo hwlat > /sys/kernel/tracing/current_tracer cat /sys/kernel/tracing/snapshot Rather than teaching every user of tr->current_trace_flags about this corner case, make sure it is never NULL: when the newly selected tracer has no flags at all, tracing_set_tracer() falls back to a static empty no_tracer_flags. run_tracer_selftest() can hit the same case, so the same fallback is added there too. The existing users already handle opts == NULL, so these tracers keep behaving as before. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20261015130658.221198-1-hao.ge@linux.dev Fixes: e29aa918a928 ("tracing: Have function graph tracer define options per instance") Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Hao Ge <hao.ge@linux.dev> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
4 daystracing/histograms: Reject non-stacktrace fields for synthetic stacktrace fieldsLee Jones1-4/+11
In check_synth_field(), when a synthetic event field is a stacktrace (field->is_stack) and the histogram field is not a "long[" stacktrace array, validation falls through to the generic size and signedness comparison. Because parse_synth_field() sets a stacktrace field's type to "__data_loc unsigned long[]", its size is sizeof(u64) and synth_field_signed() marks it as signed. Consequently, any 8-byte signed scalar histogram field passes the fallback check, and its scalar value is subsequently dereferenced as a kernel stacktrace pointer in get_field_size() and trace_stack(). Furthermore, checking strstr(hist_field->type, "long[") is insufficient because tracepoint fields defined with __bitmask() or __rel_bitmask() also have type "__data_loc unsigned long[]" or "__rel_loc unsigned long[]", whilst create_hist_field() treats them as 4-byte scalar values without HIST_FIELD_FL_STACKTRACE. Propagate HIST_FIELD_FL_STACKTRACE to variable references and field variables (whilst excluding variable aliases from per-element stacktrace capture), and reject any mismatch between HIST_FIELD_FL_STACKTRACE and field->is_stack in check_synth_field(). Cc: stable@vger.kernel.org Fixes: 00cf3d672a9d ("tracing: Allow synthetic events to pass around stacktraces") Link: https://patch.msgid.link/20261013112449.1006088-1-lee@kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
4 daysring-buffer: Use subbuf_order in available memory estimationVincent Donnefort1-4/+4
To avoid failing in the middle of an allocation of a ring-buffer, __rb_allocate_pages() looks at the available memory estimation with si_mem_available(). Use the subbuffer order with this estimation to fail early if necessary for ring-buffers with an order > 0. Link: https://patch.msgid.link/20261013102047.1488347-3-vdonnefort@google.com Fixes: f9b94daa542a ("ring-buffer: Set new size of the ring buffer sub page") Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: probes: error if BTF is required but unavailableMartin Kaiser1-2/+1
traceprobe_expand_meta_args expands probe arguments based on BTF info. Return an error if we have arguments that need expanding but BTF is not supported. The params variable is now unused, it can be removed. Link: https://lore.kernel.org/all/20261014083838.31020-1-martin@kaiser.cx/ Fixes: d157d7694460 ("tracing/probes: Support BTF field access from $retval") Signed-off-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
5 daysMerge tag 'wq-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds1-1/+1
Pull workqueue fix from Tejun Heo: - Fix a NULL dereference in the check for whether the current task is running a memory reclaim work item when called from a kworker outside work item execution * tag 'wq-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: workqueue: Fix NULL current_pwq deref in mem-reclaim helper
5 daysring-buffer: Skip si_mem_available() for persistent and remote buffersVincent Donnefort1-20/+21
Persistent and remote buffer memory is pre-allocated by the time __rb_allocate_pages() is called. Skip si_mem_available() to avoid wrongly failing the allocation under memory pressure. For the same reason, unset user_thread. Link: https://patch.msgid.link/20261013102047.1488347-2-vdonnefort@google.com Fixes: be68d63a139b ("ring-buffer: Add ring_buffer_alloc_range()") Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Do not initialize tracefs work if tracing is disabledAmit Machhiwal1-0/+6
If trace buffer allocation fails during early boot (e.g. in early_trace_init() -> allocate_trace_buffers()), tracing_disabled is left set to 1 and the global trace array events list remains uninitialized. Later during boot, tracer_init_tracefs() (invoked via fs_initcall) queues tracerfs_init_work asynchronously without checking if tracing was disabled. When tracer_init_tracefs_work_func() runs, it calls event_trace_init() and init_tracer_tracefs(&global_trace, NULL) unconditionally. This leads to __find_event_file() dereferencing an uninitialized tr->events list, causing an early boot NULL pointer dereference Oops: BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000485be0 Oops: Kernel access of bad area, sig: 7 [#1] ... NIP [c000000000485be0] __find_event_file+0x70/0x3c0 LR [c000000000448874] init_tracer_tracefs+0x274/0xc80 Call Trace: init_tracer_tracefs+0x274/0xc80 tracer_init_tracefs_work_func+0x50/0x320 process_one_work+0x1e8/0x5c0 worker_thread+0x1dc/0x3d0 kthread+0x194/0x1b0 start_kernel_thread+0x14/0x18 Check tracing_disabled at the beginning of tracer_init_tracefs_work_func() and return immediately if tracing is disabled or failed to initialize, preventing the crash. Cc: stable@vger.kernel.org Fixes: 6621a7004684 ("tracing: make tracer_init_tracefs initcall asynchronous") Link: https://patch.msgid.link/20261009163557.88467-2-amachhiw@linux.ibm.com Reported-by: Michal Suchánek <msuchanek@suse.de> Closes: https://lore.kernel.org/all/arYskzbiaNzBR9MD@kunlun.suse.cz/ Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com> Tested-by: Michal Suchánek <msuchanek@suse.de> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix hist trigger timestamps for buffered eventsTengda Wu1-1/+1
Syzkaller triggered a WARN_ON_ONCE(!nest) warning: WARNING: kernel/trace/ring_buffer.c:821 at ring_buffer_event_time_stamp Call trace: ring_buffer_event_time_stamp hist_field_timestamp hist_fn_call event_hist_trigger event_triggers_call __event_trigger_test_discard trace_event_buffer_commit do_trace_event_raw_event_sched_switch trace_event_raw_event_sched_switch The warning is probabilistically reproducible and is related to syzkaller executing the following commands: echo 'prev_pid == 999999' > events/sched/sched_switch/filter echo 'hist:keys=common_timestamp' > events/sched/sched_switch/trigger The specific triggering process is as follows: CPU 0 CPU 1 (context switching) (echo 'hist:keys=common_timestamp' > \ events/sched/sched_switch/trigger) do_trace_event_raw_event_##call trace_event_buffer_lock_reserve if (!tr->no_filter_buffering_ref && trace_file->flags & EVENT_FILE_FL_FILTERED) return entry; // return directly event_hist_trigger_parse hist_register_trigger tracing_set_filter_buffering(file->tr, true); tr->no_filter_buffering_ref++; __trace_buffer_lock_reserve rb_start_commit local_inc(&cpu_buffer->committing); // skipped and not executed trace_event_buffer_commit __event_trigger_test_discard event_triggers_call event_hist_trigger hist_fn_call hist_field_timestamp ring_buffer_event_time_stamp nest = local_read(&cpu_buffer->committing); WARN_ON_ONCE(!nest) // trigger warning The root cause is that when an event file has a filter attached and the hist trigger has not yet been attached, trace_event_buffer_lock_reserve() writes the event into the per-CPU trace_buffered_event temp buffer instead of reserving it in the ring buffer, so cpu_buffer->committing is not incremented. When the event is later processed at commit time by a hist trigger, hist_field_timestamp() -> ring_buffer_event_time_stamp() sees a zero committing count, triggering WARN_ON_ONCE(!nest). tracing_event_time_stamp() was added by commit d8279bfc5e959 ("tracing: Add tracing_event_time_stamp() API") for exactly this case: if the event is the per-CPU trace_buffered_event, it returns the current ring buffer timestamp. But it never gained a caller. Use it in hist_field_timestamp(), so that a hist trigger that races onto a buffered event records the current time, which is only marginally later than when the event was recorded, instead of warning and recording a bogus timestamp. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260929104015.1689921-1-wutengda@huaweicloud.com Fixes: b94bc80df648 ("tracing: Use a no_filter_buffering_ref to stop using the filter buffer") Signed-off-by: Tengda Wu <wutengda@huaweicloud.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix ignored return value of resize_buffer_duplicate_size()Dmitry Kandybka1-1/+4
When tr->allocated_snapshot is true, resize_buffer_duplicate_size() is called to update the snapshot buffer size. However, its return value was not checked. In case of a failed resize this could lead next snapshot being incomplete. Add resize_buffer_duplicate_size() result check and return error if resize fails. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260928152634.4354-1-d.kandybka@gmail.com Fixes: 180e4e390978 ("tracing: Add snapshot refcount") Signed-off-by: Dmitry Kandybka <d.kandybka@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daysring-buffer: Fix false warning in ring_buffer_map_get_reader()Krystian Kaniewski1-5/+1
The mmap reader can warn when it catches up with a writer that is still committing events. rb_get_reader_page() returns NULL in this case, but ring_buffer_map_get_reader() treats that result as an error. The initial rb_per_cpu_empty() check filters out an empty buffer, but it does not guarantee that the next reader page has committed data. Writers do not take reader_lock and can advance commit_page before publishing the committed length on the new page. rb_get_reader_page() can swap to that page, catch up with the writer and return NULL. Handle NULL through the existing no-data exit without warning. Remove the caller's reader_page == commit_page check as well, since the reader-page helper already handles that case. The existing metadata update and return path remain in place. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260924084946.20104-1-krystianmkaniewski@gmail.com Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions") Assisted-by: Gemini:gemini-3.8-flash syzbot Reported-by: syzbot+de3d7f9bcc9212f3fae1@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=de3d7f9bcc9212f3fae1 Link: https://syzkaller.appspot.com/ai_job?id=488adc18-a10e-42d2-a205-25327c38837f Signed-off-by: Krystian Kaniewski <krystianmkaniewski@gmail.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix simple_ring_buffer undef check on sparc64Vincent Donnefort1-0/+1
simple_ring_buffer relies on headers that end up including <asm/thread_info.h>. On sparc64, this emits the undefined symbol current_thread_info_reg. Allow this symbol. Link: https://patch.msgid.link/20260923074213.3077182-4-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix simple_ring_buffer undef check on pariscVincent Donnefort1-1/+4
simple_ring_buffer uses local_set() and cmpxchg() on unsigned long. Add them to undefsyms_base.c to extend the allowlist for the parisc architecture. Link: https://patch.msgid.link/20260923074213.3077182-3-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix empty symbol names in simple_ring_buffer undef checkVincent Donnefort1-2/+2
Sparc64 emits empty symmbol names. Skips them when establishing the allowlist and when extracing undefined symbols. Link: https://patch.msgid.link/20260923074213.3077182-2-vdonnefort@google.com Fixes: 1211907ac0b5 ("tracing: Generate undef symbols allowlist for simple_ring_buffer") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/all/5574c9e6-9ed2-4ee6-a2b2-fb6ee81e83a1@roeck-us.net/ Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daysMerge tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_extLinus Torvalds4-50/+132
Pull sched_ext fixes from Tejun Heo: - A task that skipped the BPF scheduler on its way back to its CPU's local queue could stall there until the watchdog fired, as the CPU had already decided to go idle. - Use-after-free of a destroyed user dispatch queue by a deferred re-enqueue request. - A task could be moved off a dispatch queue while the dispatching CPU was still running ops.dequeue() on it. - Bypass mode mishandled a sub-scheduler bypass overlapping an ancestor's, as across a system suspend. Descendants could leave bypass mid-teardown and tasks could be stranded on bypass queues. - The idle CPU selection helper could return a CPU outside the allowed CPUs of a pinned or migration-disabled task. * tag 'sched_ext-for-7.3-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQs sched_ext: Rename scx_reenq_wait_dispatching() to scx_wait_dispatching() sched_ext: idle: Respect task affinity in restricted CPU selection sched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestor sched_ext: Propagate every bypass depth change to the descendants sched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueue sched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQ
5 daysring-buffer: Fix the sub-buffer array base in rb_meta_subbuf_idx()Donggeun Yoo1-3/+1
On a persistent ring buffer, rb_meta_subbuf_idx() can return an index one sub-buffer too high. rb_setup_ids_meta_page() then fills subbuf_ids[] shifted by one and leaves subbuf_ids[0] NULL, which __rb_map_vma() dereferences when userspace maps trace_pipe_raw. rb_update_meta_reader() writes two such indices into meta->buffers[], which rb_cpu_meta_valid() would reject on the next boot, discarding the previous boot's trace. A CPU's sub-buffer array starts after its meta header and the nr_subbufs integers that follow, aligned up to a sub-buffer. rb_meta_subbuf_idx() inverts that calculation but skips only the integers, not the header, so its base is one sub-buffer low whenever the omitted header size crosses the alignment boundary. Invert the calculation with rb_subbufs_from_meta() rather than repeating it. rb_range_buffer() maps an index back to an address through the same helper, so the two directions can no longer disagree. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260918071507.1019251-1-donggeunyoo.kernel@gmail.com Fixes: b14d032973d4 ("ring-buffer: Add ring_buffer_meta data") Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix the shift out of bounds in the log2 histogram modifierDonggeun Yoo1-1/+1
The .log2 key modifier files a value under its base-2 order: # echo 'hist:keys=bytes_req.log2' > events/kmem/kmalloc/trigger hist_field_log2() computes that as ilog2(roundup_pow_of_two(val)). The out-of-line form of roundup_pow_of_two() is return 1UL << fls_long(n - 1); which shifts by 64 on a 64-bit kernel both when n is 0, where n - 1 wraps to ULONG_MAX, and when n is above 2^63. Both are ordinary keys, because the field fetch hands every value over as a u64: a syscall argument of 0 reaches the first, and one above 2^63 reaches the second. Keying sys_enter_lseek on offset.log2 and passing 0, 1, 2, 3, 1000, 2^63+1 and U64_MAX gives { offset: ~ 2^1 } hitcount: 1 { offset: ~ 2^10 } hitcount: 1 { offset: ~ 2^2 } hitcount: 1 { offset: ~ 2^0 } hitcount: 4 Keys above 2^63 land in the lowest bucket. With CONFIG_UBSAN_SHIFT=y the shift is also reported: UBSAN: shift-out-of-bounds in include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' __ubsan_handle_shift_out_of_bounds.cold+0xdd/0x1cb hist_fn_call.cold+0x8b/0xd9 event_hist_trigger+0x1cc/0x790 ftrace_syscall_enter+0x197/0x360 do_syscall_64+0x402/0x4b0 Use order_base_2(), which is ilog2(n - 1) + 1 for n > 1 and 0 below that. It returns what the old expression returned on every input the old one was defined for. Where it was not, 0 stays in bucket 0, which is where x86_64 had been putting it, and the keys above 2^63 move into bucket 64. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260916002735.808520-1-donggeunyoo.kernel@gmail.com Fixes: 4b94f5b7b4a5 ("tracing: Add hist trigger 'log2' modifier") Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daysring-buffer: Do not show buffer_meta for CPUs without a bufferDavid Carlier1-0/+3
The per_cpu/cpuN/buffer_meta files are created for every possible CPU, but buffer->buffers[cpu] is only allocated once that CPU comes online. Reading the file of a CPU that never came online dereferences a NULL cpu_buffer in rbm_start(). Fail the open with -ENODEV when the CPU has no buffer, as the other per CPU ring buffer interfaces do. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-3-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260913134906.6E8A01F000FF@smtp.kernel.org/ Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Take trace_types_lock when dropping the buffer_meta referenceDavid Carlier1-1/+1
tracing_buffer_meta_open() drops the trace_array reference with __trace_array_put() when ring_buffer_meta_seq_init() fails, without holding trace_types_lock. Use trace_array_put() like every other open error path. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914133506.4865-2-devnexen@gmail.com Fixes: 950032ffcee7 ("ring-buffer: Add output of ring buffer meta page") Signed-off-by: David Carlier <devnexen@gmail.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daystracing: Fix NULL dereference when copying keys for a field variableDonggeun Yoo1-1/+1
In event_hist_trigger_parse() where it needs to create actions like "onmatch", it calls: event_hist_trigger_parse() { create_actions() { action_create() { trace_action_create() { trace_action_create_field_var() { create_field_var_hist() Where create_field_var_hist() does a loop on the hist_data representing the keys. The issue is, if the keys uses one of the pseudo field types (like common_cpu), the hist_data field element will have NULL for its field member causing a NULL pointer dereference when accessing the key_field->field->name. # echo 'hist:keys=common_cpu:ts0=common_timestamp.usecs' > \ events/sched/sched_waking/trigger # echo 'my_synth u64 lat; int prio' > synthetic_events # echo 'hist:keys=common_cpu:wakeup_lat=common_timestamp.usecs-$ts0:\ onmatch(sched.sched_waking).my_synth($wakeup_lat,prio)' > \ events/sched/sched_switch/trigger KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:create_field_var_hist+0x771/0x1380 Call Trace: trace_action_create_field_var+0x360/0x600 trace_action_create+0x393/0xe80 event_hist_trigger_parse+0x3e47/0x69e0 trigger_process_regex+0x1a6/0x250 event_trigger_write+0xce/0x160 Instead of accessing it directly, use the proper handler expr_field_str() to get the name. The three previous patches are prerequisites: without them a .buckets key and a common_stacktrace key each render into a command that cannot be parsed back. Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260914053443.981201-5-donggeunyoo.kernel@gmail.com Fixes: 02205a6752f2 ("tracing: Add support for 'field variables'") Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Assisted-by: Claude:claude-fable-5 Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
5 daysfs: let idle threads share init_fsChristian Brauner1-3/+8
With nullfs as the real rootfs userspace can pivot_root() away from the initramfs and unmount it: chdir(rootfs); pivot_root(".", "."); umount2(".", MNT_DETACH); That's what systemd does and the initramfs is supposed to go away at that point together with all the memory it uses. But on every machine with more than one possible cpu the initramfs superblock stays around forever (cf. [1]). With ramfs as rootfs the unpacked initramfs shows up as Unevictable in /proc/meminfo, with tmpfs as Shmem, and it is never freed. In the reports that's between 70MB and 150MB. The idle threads of the secondary cpus are created by fork_idle() from smp_init(). That runs in kernel_init(), i.e., in PID 1, after init_userspace_fs() moved PID 1 from nullfs into the initramfs. fork_idle() doesn't pass CLONE_FS so each idle thread gets a private copy of PID 1's fs_struct and with it a reference to the initramfs as root and as pwd. pivot_root() relies on chroot_fs_refs() to move everyone whose root or pwd is the old root over to the new root. Idle threads aren't on the task list though so chroot_fs_refs() never finds them. They never exit either. So they keep the initramfs mount and with it the superblock alive for good. I overlooked this when I added nullfs. Before that the rootfs could never be unmounted anyway so it didn't matter what pinned it. Idle threads are kernel threads and init_task, the idle thread of the boot cpu, already uses init_fs. So let the idle threads of the other cpus share init_fs as well instead of copying PID 1's filesystem state. Note that kernels before 7.3 need a different backport. There PID 1 still shares init_fs with all kthreads so passing CLONE_FS in fork_idle() is enough. They also have a second pin: devtmpfsd unshares a copy of the initial mount namespace, initramfs mount included. That was fixed in commit 66d2faeccbff ("devtmpfs: create private mount namespace"). Reproducer, as /init in an initramfs together with a 128MB ballast file, booted with root=/dev/sda to get ramfs and with -smp 4: // SPDX-License-Identifier: GPL-2.0 /* initramfs /init: switch root like systemd, check the old root */ #define _GNU_SOURCE #include <fcntl.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/mount.h> #include <sys/reboot.h> #include <sys/sendfile.h> #include <sys/stat.h> #include <sys/syscall.h> #include <sys/sysmacros.h> #include <unistd.h> static void meminfo(void) { char line[256]; FILE *f = fopen("/proc/meminfo", "re"); while (f && fgets(line, sizeof(line), f)) if (!strncmp(line, "Unevictable:", 12) || !strncmp(line, "Shmem:", 6)) fputs(line, stdout); if (f) fclose(f); } int main(int argc, char *argv[]) { struct stat st; char dev[32], buf[32]; unsigned int maj, min; int fd, in, out; long r; if (argc > 1) { sleep(2); meminfo(); /* ustat() only finds live superblocks */ r = syscall(SYS_ustat, (unsigned)atoi(argv[1]), buf); printf("initramfs superblock %s\n", r ? "freed" : "pinned"); fflush(stdout); sleep(1); reboot(RB_POWER_OFF); } mount("proc", "/proc", "proc", 0, NULL); mount("devtmpfs", "/dev", "devtmpfs", 0, NULL); /* drop the fds console_on_rootfs() opened in the initramfs */ fd = open("/dev/console", O_RDWR); dup2(fd, 0); dup2(fd, 1); dup2(fd, 2); close(fd); setvbuf(stdout, NULL, _IOLBF, 0); meminfo(); stat("/", &st); maj = major(st.st_dev); min = minor(st.st_dev); /* new_encode_dev(), what ustat() expects */ snprintf(dev, sizeof(dev), "%u", (min & 0xff) | (maj << 8) | ((min & ~0xffu) << 12)); mkdir("/sysroot", 0755); mount("tmpfs", "/sysroot", "tmpfs", 0, NULL); mkdir("/sysroot/proc", 0755); mkdir("/sysroot/dev", 0755); in = open("/init", O_RDONLY); out = open("/sysroot/init", O_WRONLY | O_CREAT, 0755); fstat(in, &st); sendfile(out, in, NULL, st.st_size); close(in); close(out); mount(NULL, "/", NULL, MS_REC | MS_PRIVATE, NULL); mount("/proc", "/sysroot/proc", NULL, MS_BIND | MS_REC, NULL); mount("/dev", "/sysroot/dev", NULL, MS_BIND | MS_REC, NULL); chdir("/sysroot"); if (syscall(SYS_pivot_root, ".", ".") || umount2(".", MNT_DETACH)) perror("pivot_root"); execl("/init", "/init", dev, NULL); return 1; } Before: Unevictable: 131812 kB Shmem: 0 kB Unevictable: 131812 kB Shmem: 792 kB initramfs superblock pinned After: Unevictable: 131812 kB Shmem: 0 kB Unevictable: 0 kB Shmem: 792 kB initramfs superblock freed With -smp 1 the superblock is freed without this patch as well. [1]: https://github.com/systemd/systemd/issues/43911 Fixes: 576ee5dfd459 ("fs: add immutable rootfs") Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-2-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
5 daysfs: pass flags to copy_fs()Christian Brauner1-3/+8
Turn the umh boolean into a flags argument. Idle threads need their own case in copy_fs() as well and that's nicer than a second boolean. No functional changes. Link: https://patch.msgid.link/20261013-work-fs-idle_fs-v1-1-2063d1bcb5aa@kernel.org Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
5 dayspid_namespace: make zap_pid_ns_processes() freezableAviv Vaknin2-2/+2
When the init of a pid namespace exits, zap_pid_ns_processes() waits until all other pids in the namespace are freed. A tracer outside the namespace that does not reap its traced zombies keeps those pids allocated, so this wait has no upper bound, and while it lasts every suspend attempt fails: Freezing user space processes failed after 20.006 seconds (2 tasks refusing to freeze, wq_busy=0): Neither wait is freezable. The first loop sleeps in do_wait(), which returns -ERESTARTSYS on the freezer's fake signal; the loop then clears TIF_SIGPENDING and waits again without ever freezing. The final loop sleeps in TASK_INTERRUPTIBLE, and since nothing clears TIF_SIGPENDING there, schedule() returns immediately after the first freeze attempt and the task spins until the wait ends. Sleep in TASK_INTERRUPTIBLE | TASK_FREEZABLE in do_wait(), so that the freezer can freeze tasks waiting there directly, and in TASK_IDLE | TASK_FREEZABLE in the final loop, like coredump_task_exit() does. This was hit with Chromium-based browsers: crashpad ptrace-attaches the threads of a crashed renderer, which is a pid namespace init, and does not reap those killed during the dump. Fixes: 3eb07c8c8adb ("pid namespaces: destroy pid namespace on init's death") Fixes: b9a985db9896 ("pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes") Cc: stable@vger.kernel.org # 6.1+ Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Aviv Vaknin <vaknins33@gmail.com> Link: https://patch.msgid.link/20261002202820.3433318-1-vaknins33@gmail.com Acked-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Bradley Morgan <brads@mainlining.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
5 dayswatch_queue: Fix note pool publication race in watch_queue_set_size()Cen Zhang (Microsoft)1-4/+7
There is a race between watch_queue_set_size() and post_one_notification(). watch_queue_set_size() publishes wqueue->notes, notes_bitmap, nr_pages and nr_notes with plain stores, and post_one_notification() reads them with plain loads under a different lock, so nothing orders the four stores against the poster's loads: depending on the build, notes can be stored last (gcc 14 on x86-64 does this). Since keyctl_watch_key() lets a watch attach to a queue before it is sized, post_one_notification() can already be running on another CPU at that moment: it reads nr_notes > 0, passes its bounds check, and then reads notes while it is still NULL, dereferencing notes[0]. An unprivileged user triggers this reliably by watching one of its own keys through a notification pipe and racing ioctl(IOC_WATCH_QUEUE_SET_SIZE) on that pipe against keyctl(KEYCTL_SETPERM) on the key from another CPU, triggering: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:post_one_notification.isra.0+0xa2/0x1e0 Call Trace: __post_watch_notification+0x148/0x180 keyctl_setperm_key+0x119/0x130 do_syscall_64+0x108/0x4c0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Kernel panic - not syncing: Fatal exception in interrupt Fix this by publishing nr_notes last with smp_store_release(), and by reading it once with smp_load_acquire() in post_one_notification() before the bitmap and the page array are touched. A poster that observes a non-zero nr_notes then also observes the pool behind it; one that observes zero drops the notification as before. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: Dae R. Jeong <threeearcat@gmail.com> Closes: https://lore.kernel.org/all/ZT-S8Q7tyutcvu_q@dragonet/ Reported-by: AutonomousCodeSecurity@microsoft.com Suggested-by: Dae R. Jeong <threeearcat@gmail.com> Signed-off-by: Cen Zhang (Microsoft) <cenzhang@linux.microsoft.com> Link: https://patch.msgid.link/20261009224715.46121-1-cenzhang@linux.microsoft.com Reviewed-by: Bradley Morgan <brads@mainlining.org> Cc: <stable@vger.kernel.org> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
5 daysfutex: Fix mm reuse handling for FUT_OFF_MMSHAREDJann Horn1-23/+28
A FUT_OFF_MMSHARED futex is a shared futex that refers to an MM. It is possible for a process to wait on a shared futex with a different MM because a FUT_OFF_INODE waiter can be requeued onto a FUT_OFF_MMSHARED futex by another process. This can cause FUT_OFF_MMSHARED waiters on a freed MM to consume wakeups intended for a newly allocated MM at the same address. Fix it by keying FUT_OFF_MMSHARED using a unique 64-bit per-MM ID. Leave private futexes as before to avoid influencing the performance of the hotpath. (Multi-threaded processes typically implicitly use FUT_OFF_MMSHARED by setting clear_child_tid such that it points into anonymous memory, which causes mm_release() in a multi-threaded mm to perform FUTEX_WAKE.) Fixes: 222993395ed3 ("futex: Remove pointless mmgrap() + mmdrop()") Closes: https://lore.kernel.org/r/CAG48ez0dLBpc3QtbAhMMVNHwHL94iHh2G+h-=BVFR4dDuzZr1g@mail.gmail.com/ Signed-off-by: Jann Horn <jannh@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260929-futex-mmshared-fix-v1-1-262b1ffeb3d0@google.com Cc: stable@vger.kernel.org
5 dayssched/core: Call wakeup_preempt() for queued tasks during class changeK Prateek Nayak1-10/+9
Paul reported recent RCU changes exposed a lost resched where CPU idles with a rcutorture thread waiting while being completely runnable. Dumping the rq state at the time of idling with runnable tasks showed the following: rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1 Although the waiting task was an RT task, "rq->next_class" did not point to rt_sched_class and was stuck at the lower priority fair_sched_class. Inspecting sched_change_end() revealed the following race with __sched_setscheduler() for queued, but non-running tasks: CPU0 CPU1 ==== ==== __schedule() /* * rq->donor is a fair task that blocks. * rq->next_class = &fair_sched_class */ rq_lock(rq0) pick_next_task() /* nr_running = 0 */ pick_task_fair() sched_balance_newidle() raw_spin_rq_unlock(rq0) rq_lock(rq0) activate_task(rq0, p) /* p is a fair task */ rq0->nr_running++; rq0->cfs.h_nr_queued++; wakeup_preempt(rq, p) rq->next_class = &fair_sched_class resched_curr() rq_unlock(rq0) __sched_setscheduler(p) /* p is moved to SCHED_RR */ task_rq_lock(p) sched_change_begin() rq0->cfs.h_nr_queued--; rq0->rt.rt_nr_running++; sched_change_end() /* * p->on_rq = 1 (ctx->queued) * but p is not rq->donor * (!ctx->running) hence * resched_curr() is and * rq->next_class upgrade is * skipped. */ task_rq_unlock() raw_spin_rq_lock(rq0) /* * rq->nr_running = 1 * rq->cfs.h_nr_queued = 0 * rq->rt.rt_nr_running = 1 * rq->next_class = &fair_sched_class */ if (rq->cfs.h_nr_queued && ...) /* Above is false */ if (rq_modified_above(this_rq, &fair_sched_class)) /* Also false since rq->next_class is still fair */ /* * sched_balance_newidle() is considered to * have failed to pull any fair tasks and no * other wakeups were detected. */ return NULL; /* pick_task_fair() */ pick_task_idle() return rq->idle; next = rq->idle; /* Preemption indicators are lost */ clear_tsk_need_resched(prev); clear_preempt_need_resched(); rq->curr = rq->idle; !!! rq->idle switches in with rq->running == 1 but !need_resched() !!! In simple words, enqueue, followed by a class change of the newly queued task goes unnoticed in rq->next_class indicator and sched_balance_newidle() sees no fair task, nor any higher priority task enqueued. The above sequence will lead to CPU idling with a runnable task on the CPU. Call wakeup_preempt() for ctx->queued cases in sched_change_end() to re-evaluate rq->next_class after class change (ENQUEUE_CLASS) and set the NEED_RESCHED indicator accordingly. Newidle balance will correctly see an enqueue of a higher priority task if a queued task was upgraded when the rq_lock() was dropped and will retry the pick. Closes: https://lore.kernel.org/lkml/8fa7f795-518c-4507-b684-60b0c1cac2c5@paulmck-laptop/ Fixes: 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()") Reported-by: Paul E. McKenney <paulmck@kernel.org> Tested-by: Paul E. McKenney <paulmck@kernel.org> Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Phil Auld <pauld@redhat.com> Link: https://patch.msgid.link/20261013152455.9039-1-kprateek.nayak@amd.com
5 daysprintk: fix kernel-doc name for nbcon_write_context_is_brailleMuhammad Mahdi Amirpour1-1/+2
Use the function name in the kerneldoc description. Fixes: c83e3d291243 ("braille: nbcon: Allow to use a serial console with NBCON API as Braille console") Signed-off-by: Muhammad Mahdi Amirpour <ampr.mhd@gmail.com> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20261013151300.75966-1-ampr.mhd@gmail.com Signed-off-by: Petr Mladek <pmladek@suse.com>
6 daysnbcon/reboot: Switch NBCON consoles into the emergency mode in emergency_restart()Petr Mladek1-0/+9
When the system is going down a normal way, the NBCON kthreads are flushed and stopped properly via a syscore shutdown callback, see printk_kthreads_shutdown(). One missing piece is emergency_restart() where the kthreads are not stopped. It might be called from several non-panic code paths, e.g. sysrq-o, kdb_reboot(), or some watchdogs. Fix it by explicitly entering the emergency (atomic) mode and trying to flush the consoles there. Note that printk_trigger_flush() must be used instead of pr_flush() because the later is not safe in an atomic context. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/all/202608061008.48a1e76e-lkp@intel.com/ Suggested-by: John Ogness <john.ogness@linutronix.de> Reviewed-by: John Ogness <john.ogness@linutronix.de> Link: https://patch.msgid.link/20261013154141.94016-1-pmladek@suse.com Signed-off-by: Petr Mladek <pmladek@suse.com>
6 dayssched_ext: Wait for SCX_OPSS_DISPATCHING before moving tasks off DSQsKuba Piecuch1-3/+12
A task can be found on a non-local DSQ while the CPU which dispatched it is still running ops.dequeue() and hasn't cleared SCX_OPSS_DISPATCHING. The DSQ consume and move paths don't wait for the dispatch to finish and can operate on the task concurrently with the dispatcher. Call scx_wait_dispatching() in scx_move_local_task_to_local_dsq(), unlink_dsq_and_switch_rq_lock() and move_task_between_dsqs() before they operate on the task. In scx_move_local_task_to_local_dsq(), wait before scx_resolve_local_dsq() as it may update p->scx.flags. Fixes: ebf1ccff79c4 ("sched_ext: Fix ops.dequeue() semantics") Fixes: cb86607ada73 ("sched_ext: Don't run ops.dequeue() with a DSQ lock held") Cc: stable@vger.kernel.org # v7.1+ Reviewed-by: Andrea Righi <arighi@nvidia.com> Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch <jpiecuch@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
6 dayssched_ext: Rename scx_reenq_wait_dispatching() to scx_wait_dispatching()Kuba Piecuch3-8/+9
Waiting for SCX_OPSS_DISPATCHING to clear isn't specific to the reenqueue paths. Any path which takes a task off a DSQ can find it while the dispatch is still in flight, and the next patch calls the helper from the DSQ consume and move paths. Rename it to scx_wait_dispatching() and update its comment accordingly. No functional change. Reviewed-by: Andrea Righi <arighi@nvidia.com> Assisted-by: Claude:claude-opus-5.5 Signed-off-by: Kuba Piecuch <jpiecuch@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
7 dayssched_ext: idle: Respect task affinity in restricted CPU selectionHui Su1-11/+39
The restricted select_cpu kfunc path handles single-CPU and migration-disabled tasks without going through scx_select_cpu_dfl(). It currently uses prev_cpu as the candidate, even though prev_cpu is only a hint and may no longer be usable after an affinity change. With a caller-provided @allowed mask, this can also return an idle CPU outside p->cpus_ptr. Derive the candidate from task state instead: use the sole CPU in p->cpus_ptr for single-CPU tasks and task_cpu(p) for migration-disabled tasks. Validate it against p->cpus_ptr and @allowed before claiming its idle state. Since the derived candidate may be on a different NUMA node from prev_cpu, also preserve SCX_PICK_IDLE_IN_NODE by rejecting cross-node candidates. Perform all checks before scx_idle_test_and_clear_cpu(), as a successful call consumes the CPU's idle bit. Fixes: 683d2d0faba1 ("sched_ext: idle: Introduce scx_bpf_select_cpu_and()") Cc: stable@vger.kernel.org Signed-off-by: Hui Su <sh_def@163.com> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
7 dayssched_ext: Fix the bypass dispatch claim for schedulers bypassed by an ancestorTejun Heo1-15/+19
scx_bypass() claims bypass dispatch when the scheduler's depth goes from zero to one and releases it when the depth returns to zero, but propagates only the depth to the descendants, not the claim. A descendant that starts bypassing with its ancestor never claims, and one whose own bypass ends under the ancestor's keeps its claim, as its depth does not return to zero. A sub-scheduler enable whose bypass ends under a PM suspend thus leaks its claim: the parent keeps hosting bypass dispatch and the sub-scheduler's next bypass trips the WARN_ON_ONCE() on the claim. A sub-scheduler disable that starts under a PM suspend has no claim, so once the resume lifts the root's bypass its tasks sit on the parent's bypass DSQs with nobody consuming them. Claim for every descendant whose depth goes from zero to one in the propagation and release every scheduler in the subtree whose depth returned to zero once the tasks have moved out of the bypass DSQs. A parent that is bypassing itself when a descendant claims consumes only its own bypass DSQs, empty until it leaves bypass and becomes the host. Fixes: aa2a0a19686c ("sched_ext: Separate bypass dispatch enabling from bypass depth tracking") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
7 dayssched_ext: Propagate every bypass depth change to the descendantsTejun Heo1-7/+15
scx_bypass() propagates a depth change to the descendants only when the scheduler's own depth crosses zero, so an own bypass that starts under an ancestor's never reaches them. When the ancestor's bypass ends first, the descendants leave bypass while the scheduler is still bypassing: a sub-scheduler disabled under a PM suspend has its children re-queue their tasks through their own BPF schedulers at resume, mid-teardown. If the own bypass then ends, every descendant is decremented once more than incremented and dec_bypass_depth() warns, though no current caller gets there. Propagate on every call so that a descendant's depth is the sum of its own bypasses and its ancestors'. The early return follows the walk, as a descendant's depth is at least the scheduler's and nothing changes bypass state unless the scheduler's own does. Fixes: c7f0e467a27a ("sched_ext: Prepare bypass mode for hierarchical operation") Cc: stable@vger.kernel.org # v7.1+ Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
10 dayssched_ext: Fix use-after-free of a destroyed user DSQ by a deferred reenqueueTejun Heo1-3/+25
A deferred reenqueue can read a freed user DSQ. The request stays on its CPU's deferred list until run_deferred() takes it, and the RCU callback that frees the DSQ assumes that the grace period has flushed it, so exit_dsq() checks the per-CPU node without the deferred list lock. A grace period waits for readers in flight, not for a pending run_deferred(). A run_deferred() which starts after the grace period began can detach the request right before the callback looks and then read the freed DSQ's id. Cancel the pending requests before the grace period instead. The irq work that frees the DSQ unlinks every CPU's request under the per-CPU deferred list lock, and schedule_dsq_reenq() ignores a new request under the same lock once the id is invalid. Only a run_deferred() that started before the grace period can hold a request, and it runs with IRQs disabled, so the grace period waits for it and nothing touches the DSQ after the callback. Fixes: 84b1a0ea0b7c ("sched_ext: Implement scx_bpf_dsq_reenq() for user DSQs") Cc: stable@vger.kernel.org # v7.1+ Reported-and-tested-by: Hui Su <sh_def@163.com> Link: https://lore.kernel.org/all/20261008024753.4096008-1-sh_def@163.com/ Signed-off-by: Tejun Heo <tj@kernel.org>
10 dayssched_ext: Fix stall when a task enqueued with SCX_ENQ_LAST lands back on its CPU's local DSQTejun Heo2-4/+14
With SCX_OPS_ENQ_LAST, the last runnable task on a CPU is passed to ops.enqueue() instead of being kept running. Exiting tasks without SCX_OPS_ENQ_EXITING, migration disabled tasks without SCX_OPS_ENQ_MIGRATION_DISABLED and tasks on an offline rq skip ops.enqueue() and go straight to the local DSQ. This happens in put_prev_task_scx() after the pick has settled on idle, so nothing reschedules the CPU, which idles with the task queued until an unrelated wakeup lands on it or the watchdog fires. scx_mitosis, which sets SCX_OPS_ENQ_LAST without SCX_OPS_ENQ_EXITING, hit this during mass cgroup teardown: exiting tasks stuck in exit_mmap() for over 40 seconds. A task put on the local DSQ runs, as anywhere else. If the SCX_ENQ_LAST enqueue left the task on this CPU's local DSQ, set need_resched on the task being switched in, as proxy_resched_idle() does. resched_curr() would flag the task being put instead, and __schedule() clears that right after the pick. Fixes: f0e1a0643a59 ("sched_ext: Implement BPF extensible scheduler class") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Xiangyu Bu <xbu@meta.com> Link: https://github.com/sched-ext/scx/pull/3870 Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Dan Schatzberg <schatzberg.dan@gmail.com>
10 daysMerge tag 'dma-mapping-7.3-2026-10-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linuxLinus Torvalds1-3/+3
Pull dma-mapping fixes from Marek Szyprowski: "Two more fixes for the corner cases in the DMA-mapping SWIOTLB code (Peng Fan and Marek Szyprowski)" * tag 'dma-mapping-7.3-2026-10-09' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux: swiotlb: fix default_swiotlb_limit() for non-growable default pool iommu/dma: skip swiotlb bounce for DMA_ATTR_MMIO in iommu_dma_map_phys