aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/kernel
AgeCommit message (Collapse)AuthorFilesLines
2026-07-31Merge tag 'trace-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-traceLinus Torvalds4-4/+18
Pull tracing fixes from Steven Rostedt: - Reset dropped_count in mmio_reset_data() When mmio_reset_data() is called, it does not reset the dropped_count so that subsequent runs will have incorrect reporting. - Add NULL check for mmio_trace_array in logging functions The functions __trace_mmiotrace_rw() and __trace_mmiotrace_map() may have the 'tr' variable passed to it as NULL. But they both dereference it without checking if it is NULL first. - Check return value of __register_event() in trace_module_add_events() If __register_event() fails, the __add_event_to_tracers() call after it will create a file for it. If the module fails to load and its memory is freed, the file will still point to it and it will not be removed as the registering of the event did not complete. Only call __add_event_to_tracers() if the __register_event() was successful. - Fix false positive match in regex_match_full() The regex full matching uses a strncmp() to test against the match string and the value. It should not match if value is a prefix of the string to match. Check to make sure the length of the strings match before comparing. - Fix reader page read offset for remote buffers A page swapped in by __rb_get_reader_page_from_remote() retains its stale read offset, causing subsequent reads to skip events or read past valid data. - Fix memory leak of subbuf_ids in rb_allocate_cpu_buffer() Remote buffers allocate a subbuf_ids array. If the allocator function fails after it is allocated, it does not free it, resulting in a memory leak. * tag 'trace-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Fix subbuf_ids memory leak in rb_allocate_cpu_buffer() error path ring-buffer: Fix reader page read offset for remote buffers tracing/filters: Fix false positive match in regex_match_full() tracing: Check return value of __register_event() in trace_module_add_events() tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions tracing/mmiotrace: Reset dropped_count in mmio_reset_data()
2026-08-01bpf: Reject >8 byte return values on return-reading trampoline pathsYonghong Song2-0/+37
btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init(). Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Reviewed-by: Eduard Zingerman <eddyz87@gmail.com> Acked-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/bpf/20260729050159.2585809-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-31ring-buffer: Fix subbuf_ids memory leak in rb_allocate_cpu_buffer() error pathMasami Hiramatsu (Google)1-0/+1
In rb_allocate_cpu_buffer(), cpu_buffer->subbuf_ids is allocated using kcalloc() when buffer->remote is non-NULL. If a subsequent page allocation fails (e.g., ring_buffer_desc_page() returns NULL or rb_allocate_pages() fails), execution jumps to fail_free_reader. While __free(kfree) automatically frees the outer cpu_buffer structure at scope exit, kfree(cpu_buffer) does not recursively free nested heap pointers such as cpu_buffer->subbuf_ids, resulting in a memory leak. Fix this by explicitly freeing cpu_buffer->subbuf_ids in the fail_free_reader error unwinding path when cpu_buffer->remote is set. Link: https://patch.msgid.link/178550740672.380917.6067449683620196150.stgit@devnote2 Fixes: 2e67fabd8b77 ("ring-buffer: Introduce ring-buffer remotes") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2026-07-31bpf: Propagate untrusted pointer state in commuted arithmeticYiyang Chen1-7/+7
The untrusted PTR_TO_MEM early return skips pointer offset tracking because accesses go through probe-read handling. Moving it after full pointer-state propagation ensures scalar += untrusted_pointer leaves the destination as PTR_TO_MEM instead of an unrelated scalar. Fixes: f2362a57aeff ("bpf: allow void* cast using bpf_rdonly_cast()") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Tested-by: Daniel Wade <danjwade95@gmail.com> Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-3-8ee297e2346b@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-31bpf: Preserve pointer state for commuted arithmeticYiyang Chen1-7/+8
When scalar += pointer is handled in adjust_ptr_min_max_vals(), the destination register inherits the pointer state from the source pointer. Copying only selected fields is fragile because pointer provenance is tracked by several bpf_reg_state fields. Use the caller's temporary offset register to preserve the scalar operand while replacing the destination with the full pointer state. This preserves the frame number for PTR_TO_STACK registers and keeps parent identity fields consistent. Fixes: f4d7e40a5b71 ("bpf: introduce function calls (verification)") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Tested-by: Daniel Wade <danjwade95@gmail.com> Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-2-8ee297e2346b@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-31bpf: Simplify sanitize_err() signatureEduard Zingerman1-9/+7
The sanitize_err() function is called when: - ptr += scalar - scalar += ptr - scalar += scalar ALU operations are processed. This commit drops offset and pointer registers parameters from its signature to simplify the follow-up changes for 'scalar += ptr' case. regs[src].type is safe to access, as it is not mutated by the callers. Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Acked-by: Shung-Hsi Yu <shung-hsi.yu@suse.com> Link: https://patch.msgid.link/20260729-c3-035-public-bpf-v4-v4-1-8ee297e2346b@mails.tsinghua.edu.cn Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-31rv: Add KUnit tests for some LTL monitorsGabriele Monaco7-0/+180
Validate the functionality of LTL monitors by injecting events in a controlled environment (KUnit) and expecting reactions, just like it is done in DA monitors. Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260723074534.43521-15-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-07-31rv: Add KUnit mock for currentGabriele Monaco5-14/+44
Some monitors do not only rely on tracepoint arguments but also on the currently executing task. This makes it more challenging to mock events in KUnit. Define wrapper functions around current, the functionality is mocked only during KUnit, an additional function call is avoided using a static branch unless any (even unrelated) KUnit test is running. Rely on a global mock_current variable that is set only by the RV KUnit tests and cleared on teardown. Unrelated KUnit tests that happen to trigger RV handlers would see it null and use current. Reviewed-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Wen Yang <wen.yang@linux.dev> Link: https://lore.kernel.org/r/20260723074534.43521-14-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-07-31rv: Add KUnit tests for some DA/HA monitorsGabriele Monaco19-0/+622
Validate the functionality of DA monitors by injecting events in a controlled environment (KUnit) and expecting reactions. Events handlers are exported directly from the monitor source files without using system events and with dummy arguments (e.g. no real tasks). If the provided sequence of events incurs a violation, the test expects the stub version of rv_react() to be called. This testing method can validate the entire monitor implementation since it sits between the monitor and the system (in place of the tracepoints). All sorts of system and timing events can be emulated without affecting the running kernel. Handlers and monitor functions are exported as part of a struct to simplify the process of running KUnit tests from kernel modules. Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260723074534.43521-13-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-07-31rv: Export task monitor slot and react symbolsGabriele Monaco2-0/+3
Export rv_get_task_monitor_slot, rv_put_task_monitor_slot, and rv_react to GPL modules so they can be accessed by KUnit and future monitors built as kernel modules. Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260723074534.43521-12-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-07-31Merge back cpufreq material for 7.3Rafael J. Wysocki1-3/+5
* pm-cpufreq: cpufreq/amd-pstate: handle missing policy in dynamic EPP callbacks cpufreq/amd-pstate: Cache the firmware programmed EPP value cpufreq/amd-pstate: Toggle auto_sel in active mode on shared memory systems cpufreq/amd-pstate: Fix EPP return type and handle errors during initialization cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active cpufreq: schedutil: Replace sprintf() with sysfs_emit() in sysfs show cpufreq: schedutil: Fix self-contradictory comment in sugov_iowait_apply() Documentation: admin-guide: cpufreq: fix sampling_rate example command cpufreq: intel_pstate: Move two functions closer to callers cpufreq: intel_pstate: Consolidate frequency values computation cpufreq: intel_pstate: Introduce intel_pstate_update_freq_limits() cpufreq: intel_pstate: Fix setting minimum P-state at init time cpufreq: intel_pstate: Rename INTEL_PSTATE_HWP_BROADWELL cpufreq: intel_pstate: Simplify HWP handling on Broadwell cpufreq: intel_pstate: Adjust the .adjust_perf() driver callback cpufreq: intel_pstate: Rearrange checks in hybrid_get_cost()
2026-07-31rv: Use generic rv_this for the rv_monitor variable in LTLGabriele Monaco2-6/+6
Align the rv_monitor variable name in LTL to the generic rv_this as it is already done for DA/HA monitors. This improves consistency and eases assumptions across model classes. Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://lore.kernel.org/r/20260723074534.43521-2-gmonaco@redhat.com Signed-off-by: Gabriele Monaco <gmonaco@redhat.com>
2026-07-31stop_machine: Make stop_one_cpu_nowait() return voidYury Norov1-8/+6
No caller checks the return value from stop_one_cpu_nowait(). All callers require the callback to run and arrange for the target CPU's stopper to remain enabled while queuing the work. In particular, commit f0498d2a54e7 ("sched: Fix stop_one_cpu_nowait() vs hotplug") added preemption protection to the scheduler callers so that queuing must succeed once the target CPU has been observed online. Therefore, a failure is an unrecoverable violation rather than a condition individual callers can recover from. Diagnose it with WARN_ON_ONCE() in stop_one_cpu_nowait(). A check in the common helper covers current and future callers consistently, while individual checks would duplicate the same non-recoverable handling at every call site. Make the function return void because there is no longer a meaningful result for callers to consume. On UP, warn if the supplied CPU is not the current CPU because the work cannot be scheduled in that case. Signed-off-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com> Link: https://patch.msgid.link/20260729022355.325058-1-ynorov@nvidia.com
2026-07-31Merge branch 'perf/urgent' into perf/core, to pick up fixesIngo Molnar39-255/+675
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2026-07-31locking/percpu-rwsem: Annotate intentional data race in readers_active_check()Sun Shaojie1-1/+1
KCSAN reports a data race between readers_active_check() and a concurrently executing reader: BUG: KCSAN: data-race in readers_active_check / percpu_down_write race at unknown origin, with read to 0xffff9f3eb5bf5f30 of 4 bytes by task 1271 on cpu 14: readers_active_check+0x... percpu_down_write+0x152/0x1f0 value changed: 0xfffffff9 -> 0xfffffff8 readers_active_check() calls per_cpu_sum(*sem->read_count), which iterates over all CPUs and reads each CPU's per-CPU read_count variable. Concurrently, a reader on a remote CPU is modifying its own CPU's read_count via this_cpu_inc() / this_cpu_dec() as it enters and exits the critical section. These are plain reads and writes to the same per-CPU storage, hence KCSAN flags a data race. This race is benign. readers_active_check() is called from the percpu_down_write() wait loop (rcuwait_wait_event) after sem->block is already set. At this point: - New readers must immediately back out (they see block set, decrement their counter, and wake the writer), so counters can only decrease. - If the sum catches a reader's increment before its decrement, readers_active_check() sees a non-zero sum and returns false. The writer merely iterates the wait loop again -- a harmless retry. - A false zero (observing sum == 0 while a reader is still active) cannot happen: per_cpu_sum() reads each CPU's counter, and each per-CPU int read is atomic on all architectures, so an active reader's counter is always seen as non-zero. Annotate the read with data_race() to suppress the KCSAN warning and document the intentional nature of this unlocked access. Signed-off-by: Sun Shaojie <sunshaojie@kylinos.cn> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260623104132.505117-1-sunshaojie@kylinos.cn
2026-07-31locking/lockdep: Fix NULL pointer dereference in __lock_set_class()Naveen Kumar Chaudhary1-0/+2
register_lock_class() can return NULL when the lock class pool is exhausted, graph_lock() fails, or key validation fails. However, __lock_set_class() uses the return value directly in pointer arithmetic without a NULL check: class = register_lock_class(lock, subclass, 0); hlock->class_idx = class - lock_classes; If class is NULL, this computes a wild offset that corrupts hlock->class_idx. The subsequent reacquire_held_locks() call will invoke hlock_class() with this corrupted index, leading to a NULL or out-of-bounds pointer dereference. Add the missing NULL check, consistent with how __lock_acquire() already handles this case at the same call site. Fixes: 64aa348edc61 ("lockdep: lock_set_subclass - reset a held lock's subclass") Signed-off-by: Naveen Kumar Chaudhary <naveen.osdev@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Waiman Long <longman@redhat.com> Reviewed-by: Dmitry Ilvokhin <d@ilvokhin.com> Link: https://patch.msgid.link/h2kfw43n4527x6mgi2lwpz2rieqnfzgictpv4wr5nyfjkc47co@2r5vz4uz44db
2026-07-31uprobes: Fix NULL pointer dereference in hprobe_expire()Breno Leitao1-1/+1
Forking a task that has a pending uretprobe can oops the kernel with a NULL pointer dereference in the clone() path: BUG: kernel NULL pointer dereference, address: 0000000000000018 Oops: 0002 [#1] SMP NOPTI RIP: 0010:hprobe_expire CR2: 0000000000000018 Call Trace: uprobe_copy_process copy_process kernel_clone __x64_sys_clone do_syscall_64 entry_SYSCALL_64_after_hwframe This was found on real hosts on Meta fleet. I've got the impression that this is what is happening: CPU 1 CPU 2 (traced task) ----- ------------------- hit uprobe, prepare_uretprobe(): hprobe LEASED, refcount >= 1 uprobe_unregister() put_uprobe(): refcount -> 0 fork() -> dup_utask() hprobe_expire(hprobe, true) try_get_uprobe() -> NULL get_uprobe(NULL) <-- Oops Only take the extra reference when the uprobe is non-NULL; a NULL means it is gone and is the correct value to return. Fixes: dd1a7567784e ("uprobes: SRCU-protect uretprobe lifetime (with timeout)") Signed-off-by: Breno Leitao <leitao@debian.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Andrii Nakryiko <andrii@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260729-uprobe-v1-1-61896b87c867@debian.org
2026-07-31swiotlb: remove unused SWIOTLB_FORCE flagAneesh Kumar K.V (Arm)1-2/+1
SWIOTLB_FORCE has no remaining in-tree users. Forced bouncing is now controlled through the swiotlb=force command line option via swiotlb_force_bounce. Remove the unused flag and simplify the force_bounce initialization. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-24-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: handle set_memory_decrypted() failuresAneesh Kumar K.V (Arm)1-15/+65
Check the return value when converting swiotlb pools between encrypted and decrypted mappings. If the default pool cannot be decrypted after early initialization, mark the pool fully used so it cannot satisfy future bounce allocations. For late initialization, return the `set_memory_decrypted()` failure. For restricted DMA pools, fail device initialization if the reserved pool cannot be decrypted. This prevents swiotlb from using pools whose encryption attributes do not match their metadata, and avoids returning pages with uncertain encryption state back to the allocator. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-23-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: free dynamic pools from process contextAneesh Kumar K.V (Arm)1-8/+11
swiotlb_dyn_free() is used after removing a dynamic swiotlb pool from RCU-protected lists. It can call swiotlb_free_tlb(), which may need to restore the encryption state of an unencrypted pool with set_memory_encrypted() before freeing the pages. RCU callbacks run in atomic context, but set_memory_encrypted() is not guaranteed to be atomic-safe on all architectures. For example, page attribute updates may allocate page tables or take sleeping locks. Use queue_rcu_work() for dynamic pool freeing instead. This keeps the RCU grace period before freeing a published pool, while running the actual pool teardown from workqueue context. Use the same helper for the transient-pool error path, since that path may also be reached from atomic DMA mapping context. Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-22-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: rename ret to cpu_addr in alloc helpersAneesh Kumar K.V (Arm)1-20/+20
ret in dma_direct_alloc() and dma_direct_alloc_pages() holds the returned CPU mapping, not a generic return value. Rename it to cpu_addr and update the remaining uses to match. This makes the allocation paths easier to follow and keeps the local naming consistent with what the variable actually represents. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-21-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: select DMA address encoding from __DMA_ATTR_ALLOC_CC_SHAREDAneesh Kumar K.V (Arm)1-17/+26
Make the dma-direct helpers derive the DMA address encoding from __DMA_ATTR_ALLOC_CC_SHARED instead of implicitly relying on force_dma_unencrypted() inside phys_to_dma_direct() Pass an explicit unencrypted/decrypted state into phys_to_dma_direct(), make the alloc paths return DMA addresses that match the requested buffer encryption state. Also only call dma_set_decrypted() when __DMA_ATTR_ALLOC_CC_SHARED is actually set. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-20-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: set decrypted flag for remapped DMA allocationsAneesh Kumar K.V (Arm)1-12/+44
Devices that are DMA non-coherent and require a remap were skipping dma_set_decrypted(), leaving DMA buffers encrypted even when the device requires unencrypted access. Move the call after the if (remap) branch so that both the direct and remapped allocation paths correctly mark the allocation as decrypted (or fail cleanly) before use. Fix dma_direct_alloc() and dma_direct_free() to apply set_memory_*() to the linear-map alias of the backing pages instead of the remapped CPU address. Also disallow highmem pages for __DMA_ATTR_ALLOC_CC_SHARED, because highmem buffers do not provide a usable linear-map address. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-19-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHAREDAneesh Kumar K.V (Arm)1-22/+30
Teach dma_direct_map_phys() to select the DMA address encoding based on DMA_ATTR_CC_SHARED. Use phys_to_dma_unencrypted() for decrypted mappings and phys_to_dma_encrypted() otherwise. If a device requires unencrypted DMA but the source physical address is still encrypted, force the mapping through swiotlb so the DMA address and backing memory attributes remain consistent. Update the arm64, x86, s390 and powerpc secure-guest setup to not use swiotlb force option Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-18-aneesh.kumar@kernel.org [mszyprow: rebased onto latest changes in arch/arm64/mm/init.c] Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: Move dma_direct_map_phys() to dma/direct.cAneesh Kumar K.V (Arm)2-53/+56
dma_direct_map_phys() is too large to benefit from being inlined. Move its implementation to direct.c and leave the declaration in direct.h. No functional change in this patch Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-17-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checksAneesh Kumar K.V (Arm)2-4/+4
Teach dma_capable() about DMA_ATTR_CC_SHARED so the capability check can reject encrypted DMA addresses for devices that require unencrypted/shared DMA. Also propagate DMA_ATTR_CC_SHARED in swiotlb_map() when the selected SWIOTLB pool is decrypted so the capability check sees the correct DMA address attribute. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-16-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-mapping: make dma_pgprot() honor __DMA_ATTR_ALLOC_CC_SHAREDAneesh Kumar K.V (Arm)2-9/+15
Fold encrypted/decrypted pgprot selection into dma_pgprot() so callers do not need to adjust the page protection separately. Update dma_pgprot() to apply pgprot_decrypted() when DMA_ATTR_CC_SHARED or __DMA_ATTR_ALLOC_CC_SHARED is set and pgprot_encrypted() otherwise Convert the dma-direct mmap paths to pass DMA_ATTR_CC_SHARED instead of open-coding force_dma_unencrypted() handling around dma_pgprot(). Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-15-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHAREDAneesh Kumar K.V (Arm)2-46/+144
Teach swiotlb to distinguish between encrypted and decrypted bounce buffer pools, and make allocation and mapping paths select a pool whose state matches the requested DMA attributes. Add a cc_shared flag to io_tlb_mem, initialize it for the default and restricted pools, and propagate __DMA_ATTR_ALLOC_CC_SHARED into swiotlb pool allocation. Reject swiotlb alloc/map requests when the selected pool does not match the required encrypted/decrypted state. Also return DMA addresses with the matching phys_to_dma_{encrypted, unencrypted} helper so the DMA address encoding stays consistent with the chosen pool. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-14-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: swiotlb: pass mapping attributes by referenceAneesh Kumar K.V (Arm)1-3/+3
Change swiotlb_tbl_map_single() to take the DMA mapping attributes by reference and update the direct callers accordingly. This is a preparatory change for a follow-up patch which updates the attributes based on the selected swiotlb pool. Keeping the signature change separate makes the follow-up patch easier to review. No functional change in this patch. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-13-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-pool: track decrypted atomic pools and select them via attrsAneesh Kumar K.V (Arm)3-72/+132
Teach the atomic DMA pool code to distinguish between encrypted and unencrypted pools, and make pool allocation select the matching pool based on DMA attributes. Introduce a dma_gen_pool wrapper that records whether a pool is unencrypted, initialize that state when the atomic pools are created, and use it when expanding and resizing the pools. Update dma_alloc_from_pool() to take attrs and skip pools whose encrypted state does not match __DMA_ATTR_ALLOC_CC_SHARED. Update dma_free_from_pool() accordingly. Also pass __DMA_ATTR_ALLOC_CC_SHARED from the swiotlb atomic allocation path so decrypted swiotlb allocations are taken from the correct atomic pool. Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-12-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: use __DMA_ATTR_ALLOC_CC_SHARED in alloc/free pathsAneesh Kumar K.V (Arm)2-9/+42
Propagate force_dma_unencrypted() into __DMA_ATTR_ALLOC_CC_SHARED in the dma-direct allocation path and use the attribute to drive the related decisions. This updates dma_direct_alloc(), dma_direct_free(), and dma_direct_alloc_pages() to fold the forced unencrypted case into attrs. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-11-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pagesAneesh Kumar K.V (Arm)2-18/+59
Move swiotlb allocation out of __dma_direct_alloc_pages() and handle it in dma_direct_alloc() / dma_direct_alloc_pages(). This is needed for follow-up changes that simplify the handling of memory encryption/decryption based on the DMA attribute flags. swiotlb backing pages are already mapped decrypted by swiotlb_update_mem_attributes() and rmem_swiotlb_device_init(), so dma-direct should not call dma_set_decrypted() on allocation nor dma_set_encrypted() on free for swiotlb-backed memory. Update alloc/free paths to detect swiotlb-backed pages and skip encrypt/decrypt transitions for those paths. Keep the existing highmem rejection in dma_direct_alloc_pages() for swiotlb allocations. Only for "restricted-dma-pool", we currently set `for_alloc = true`, while rmem_swiotlb_device_init() decrypts the whole pool up front. This pool is typically used together with "shared-dma-pool", where the shared region is accessed after remap/ioremap and the returned address is suitable for decrypted memory access. So existing code paths remain valid. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Jiri Pirko <jiri@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-8-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31swiotlb: Preserve allocation virtual address for dynamic poolsAneesh Kumar K.V (Arm)1-12/+19
swiotlb_alloc_tlb() can allocate from the DMA atomic pool when a decrypted pool is needed from atomic context. With CONFIG_DMA_DIRECT_REMAP, the atomic pool is backed by remapped virtual addresses, which are not the same as the direct-map addresses returned by phys_to_virt(). swiotlb_init_io_tlb_pool() currently reconstructs the pool virtual address from the physical start address. For atomic-pool backed allocations this stores the wrong address in pool->vaddr. Later, swiotlb_free_tlb() passes that address to dma_free_from_pool(), which will fail to recognize the chunk Pass the virtual address returned by the allocation path into swiotlb_init_io_tlb_pool(), and store that address in pool->vaddr. This keeps the pool free path using the same virtual address as the allocator. Fixes: 79636caad361 ("swiotlb: if swiotlb is full, fall back to a transient memory pool") Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Petr Tesarik <ptesarik@suse.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-6-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma: free atomic pool pages by physical addressAneesh Kumar K.V (Arm)2-2/+63
dma_direct_alloc_pages() may satisfy atomic allocations from the coherent atomic pools. The pool allocation is keyed by the virtual address stored in the gen_pool, but the pages API returns only the backing struct page. On architectures with CONFIG_DMA_DIRECT_REMAP, atomic pool chunks are added to the gen_pool using their remapped virtual address. dma_direct_free_pages() reconstructs a linear-map address with page_address(page) and passes that to dma_free_from_pool(). That address does not match the gen_pool virtual range, so the pool lookup can fail and the code can fall through to freeing a pool-owned page through the normal page allocator path. Add a page-based pool free helper that looks up the owning pool chunk by physical address, translates it back to the gen_pool virtual address, and frees that address to the pool. Use it from dma_direct_free_pages() while keeping the existing virtual-address helper for coherent allocation frees. Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-5-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-pool: fix page leak in atomic_pool_expand() cleanupAneesh Kumar K.V (Arm)1-3/+7
atomic_pool_expand() frees the allocated pages from the remove_mapping error path only when CONFIG_DMA_DIRECT_REMAP is enabled. When CONFIG_DMA_DIRECT_REMAP is disabled, failures after page allocation, such as gen_pool_add_virt(), jump to remove_mapping and return without freeing the pages. Move __free_pages(page, order) out of the CONFIG_DMA_DIRECT_REMAP block so that cleanup paths always release the allocation. Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Link: https://lore.kernel.org/r/20260717180442.110954-3-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-31dma-direct: return struct page from dma_direct_alloc_from_pool()Aneesh Kumar K.V (Arm)1-8/+10
Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *. Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller. Fixes: 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") Cc: stable@vger.kernel.org Tested-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org> Reviewed-by: Mostafa Saleh <smostafa@google.com> Link: https://lore.kernel.org/r/20260717180442.110954-2-aneesh.kumar@kernel.org Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2026-07-30bpf: Log error code on trampoline unlink failureXu Xin2-7/+13
Replace silent WARN_ON_ONCE with WARN_ONCE that prints the actual error code from bpf_trampoline_unlink_prog(). This aids debugging of race conditions during link teardown, while keeping the warning rate limited to avoid log flooding. This will be very helpful for speeding up trouble-shooting of some crash UAF due to bpf_trampoline_unlink_prog failures. No change to unlink behavior. Signed-off-by: Xu Xin <xu.xin16@zte.com.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/bpf/20260729141159128mEJmS_aujBKr-cBu1p_UI@zte.com.cn
2026-07-30bpf: Fix potential UAF when reading bpf link infoPu Lehui1-4/+17
In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue. Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields. Fixes: 0c991ebc8c69 ("bpf: Implement bpf_prog replacement for an active bpf_cgroup_link") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728025457.2814876-1-pulehui@huaweicloud.com
2026-07-30bpf: Fix potential UAF in bpf_netns_link_update_progPu Lehui1-11/+6
In bpf_netns_link_update_prog, the checks for old_prog and prog type are currently performed locklessly before acquiring netns_bpf_mutex. This creates a race condition that can lead to a UAF issue. If two threads concurrently execute BPF_LINK_UPDATE on the same netns link, the following execution path can trigger a UAF: CPU0 CPU1 bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) return -EPERM; bpf_netns_link_update_prog if (old_prog && old_prog != link->prog) ... old_prog = xchg(&link->prog, new_prog); bpf_prog_put(old_prog); if (new_prog->type != link->prog->type) <-- trigger UAF Fix this by moving the old_prog and prog->type checks inside the netns_bpf_mutex critical section. Meanwhile, use guard() to simplify lock management and avoid all the goto jumping. Fixes: 7f045a49fee0 ("bpf: Add link-based BPF program attachment to network namespace") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Reviewed-by: Amery Hung <ameryhung@gmail.com> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/f87b53c0-8f00-45a6-82db-8242fa9b143f@huaweicloud.com [0] Link: https://lore.kernel.org/bpf/20260728023259.2813482-1-pulehui@huaweicloud.com
2026-07-30Merge tag 'audit-pr-20260730' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/auditLinus Torvalds2-4/+13
Pull audit fixes from Paul Moore: - Fix potential integer overflows in audit_log_n_string() Similar to the earlier fix to audit_log_n_hex() that you merged earlier in July. Expect a cleaner, and generally better fix for these functions in an upcoming merge window, but this addresses the problem in a small patch that should be easy for people to backport. - Fix potential use-after-free in audit_del_rule() * tag 'audit-pr-20260730' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit: audit: fix potential use-after-free in audit_del_rule() audit: fix potential integer overflow in audit_log_n_string()
2026-07-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski14-23/+103
Cross-merge networking fixes after downstream PR (net-7.2-rc6). No conflicts. Adjacent changes: net/ipv4/route.c dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails") 7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()") drivers/net/tun.c 23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()") c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"") drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c 3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state") 5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use") drivers/net/wireless/ath/ath12k/core.h drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/peer.c 469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event") 378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter") c42b27336eef ("wifi: ath12k: fix survey indexing across bands") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30Merge tag 'pm-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds1-0/+11
Pull power management fixes from Rafael Wysocki: "These fix issues related to cpufreq, in the ACPI CPPC library and the generic CPPC cpufreq driver, in the powernow-k8 and amd-pstate drivers, and in the schedutil governor: - Allow fast frequency switching in the ACPI CPPC library only when every supported control used by the driver callback has an address space already accepted for fast access (Christian Loehle) - Skip writes to unsupported performance controls in the ACPI CPPC library (Christian Loehle) - Update cppc_cpufreq_update_perf_limits() to read policy->min and policy->max once and, if the lockless snapshot is inconsistent, reduce the minimum to the observed maximum, along the lines of cpufreq_driver_resolve_freq() (Christian Loehle) - Fix a possible memory leak in the powernowk8_cpu_init() error paths (Abdun Nihaal) - Loosen the requirement on lowest nonlinear frequency != min freq in the amd-pstate driver that is too tight for new systems some of which actually have the lowest nonlinear frequency identical to the minimum frequency (Mario Limonciello) - Prevent amd-pstate from loading on unsupported hardware (Rong Zhang) - Address an initialization race in the schedutil governor when it runs on multi-CPU cpufreq policies, by making it initialize all per-CPU structures first and only then publish the per-CPU utilization update hooks (Zhongqiu Han)" * tag 'pm-7.2-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: powernow-k8: Fix possible memory leak in powernowk8_cpu_init() ACPI: CPPC: Skip writes to unsupported performance controls cpufreq/amd-pstate: Prevent the driver from loading on unsupported hardware cpufreq/amd-pstate: Loosen requirement on lowest nonlinear frequency != min freq cpufreq: schedutil: Publish util hooks only after all sg_cpu are initialized cpufreq: cppc: Sanitize lockless policy limit snapshots ACPI: CPPC: Check all controls for fast switching
2026-07-30rcu-tasks: Fix some comments for call_rcu_tasks() and call_rcu_tasks_rude()Zqiang1-4/+4
The comments for call_rcu_tasks() and call_rcu_tasks_rude() referred to "RCU read-side critical sections", which is ambiguous. specify "rcu-tasks" and "rcu-tasks rude" respectively to match the actual flavor being described. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu-tasks: Rename tasks_rcu_exit_srcu_stall_timer to tasks_rcu_exit_stall_timerZqiang1-8/+8
This 'commit 1612160b9127 ("rcu-tasks: Eliminate deadlocks involving do_exit() and RCU tasks")' has reimplemented the rcu_tasks_postscan(), and the synchronize_srcu() has been removed, this commit therefore rename tasks_rcu_exit_srcu_stall_timer to tasks_rcu_exit_stall_timer. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu: Mark interrupts-enabled accesses to rdp->cpu_no_qs.sPaul E. McKenney1-1/+1
The rdp->cpu_no_qs.s field is accessed only by the current CPU, but can be accessed both at task level and from interrupt handlers. All accesses from interrupts-enabled code must therefore be marked. This commit therefore converts from __this_cpu_read() to this_cpu_read(), but only in interrupts-enabled code, that is, the rcu_qs() function. KCSAN located this issue. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu: Reduce stack usage in show_rcu_gp_kthreads()Zqiang1-18/+29
When CONFIG_KASAN=y and CONFIG_KASAN_STACK=y builds, the show_rcu_gp_kthreads() exceeds the 1024-byte frame-size limit: make kernel/rcu/tree.o KCFLAGS="-fstack-usage" DESCEND objtool DESCEND bpf/resolve_btfids INSTALL libsubcmd_headers CC kernel/rcu/tree.o In file included from kernel/rcu/tree.c:4998: kernel/rcu/tree_stall.h: In function 'show_rcu_gp_kthreads': kernel/rcu/tree_stall.h:994:1: warning: the frame size of 1656 bytes is larger than 1024 bytes [-Wframe-larger-than=] grep show_rcu kernel/rcu/tree.su tree_nocb.h:1622:13:show_rcu_nocb_state 896 dynamic,bounded tree_stall.h:933:6:show_rcu_gp_kthreads 1784 dynamic,bounded tree_stall.h:1102:13:sysrq_show_rcu 16 static Wrap the pr_info() into two noinline_for_stack helpers function: show_rcu_state() print rcu_state status, and show_rcu_node() print single rcu_node status. After apply this change: grep show_rcu kernel/rcu/tree.su tree_stall.h:955:22:show_rcu_node 696 dynamic,bounded tree_stall.h:930:22:show_rcu_state 872 dynamic,bounded tree_nocb.h:1622:13:show_rcu_nocb_state 896 dynamic,bounded tree_stall.h:972:6:show_rcu_gp_kthreads 544 static tree_stall.h:1113:13:sysrq_show_rcu 16 static Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu: Mark accesses to ->rcu_urgent_qs and ->rcu_need_heavy_qsItai Handler1-5/+5
rcu_all_qs() and rcu_note_context_switch() read/clear the per-CPU ->rcu_urgent_qs and ->rcu_need_heavy_qs flags with plain raw_cpu_read() and this_cpu_write(), while the RCU core clears them with WRITE_ONCE() in rcu_disable_urgency_upon_qs(). KCSAN flags the resulting same-CPU race: BUG: KCSAN: data-race in rcu_all_qs / rcu_disable_urgency_upon_qs It is benign -- the flags are advisory and rcu_all_qs() re-reads ->rcu_urgent_qs with smp_load_acquire() before acting on it -- but these are the last unmarked accesses to the two flags; every other access already uses READ_ONCE()/WRITE_ONCE()/smp_*. Mark them to match. No functional change. Reproduced on a PREEMPT_NONE, CONFIG_KCSAN_INTERRUPT_WATCHER=y kernel with a pthreads program whose threads (two per CPU) loop reading a large file: for (;;) { int fd = open("/proc/kallsyms", O_RDONLY); while (read(fd, buf, sizeof(buf)) > 0) ; close(fd); } The read()s drive cond_resched() -> rcu_all_qs() while the busy CPUs keep the grace period urgent, so the RCU core clears the flags concurrently. Fixes: 2dba13f0b6c2 ("rcu: Switch urgent quiescent-state requests to rcu_data structure") Signed-off-by: Itai Handler <itai.handler@gmail.com> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu: Remove unused rdp parameter from rcu_check_gp_start_stall()Zqiang3-6/+4
The rcu_check_gp_start_stall() works entirely on rnp parameter, and never uses it's rdp parameter. this commit therefore drop it, updating both callers and the declaration. No functional change. Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30rcu: Mark interrupts-enabled accesses to rdp->cpu_no_qs.b.normPaul E. McKenney2-5/+5
The rdp->cpu_no_qs.b.norm field is accessed only by the current CPU, but can be accessed both at task level and from interrupt handlers. All accesses from interrupts-enabled code must therefore be marked. This commit therefore converts from __this_cpu_read() to this_cpu_read(), from __this_cpu_write() to this_cpu_write(), and plain C-language accesses to READ_ONCE() and WRITE_ONCE(), but only in interrupts-enabled code. KCSAN located this issue. Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
2026-07-30sched/deadline: Use revised wakeup rule only for running dl_serverGabriele Monaco1-1/+2
Commit 14a857056466 ("sched/deadline: Use revised wakeup rule for dl_server") applies the revised wakeup rule to any server, as a result servers that are not running (dl_defer_running == 0) and start with a deadline overflow get enqueued and can boost tasks as if they were running, invalidating the defer rule and the documented state model. Apply the revised wakeup rule only for deferrable servers that are marked as running. Fixes: 14a857056466 ("sched/deadline: Use revised wakeup rule for dl_server") Signed-off-by: Gabriele Monaco <gmonaco@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Juri Lelli <juri.lelli@redhat.com> Tested-by: Andrea Righi <arighi@nvidia.com> Link: https://patch.msgid.link/20260522125833.264145-1-gmonaco@redhat.com