user/sven/linux.git/kernel, branch v6.12.74

cpuset: Fix missing adaptation for cpuset_is_populated

2026-02-19T15:29:55Z

Commit b1bcaed1e39a ("cpuset: Treat cpusets in attaching as populated") was backported to the long‑term support (LTS) branches. However, because commit d5cf4d34a333 ("cgroup/cpuset: Don't track # of local child partitions") was not backported, a corresponding adaptation to the backported code is still required. To ensure correct behavior, replace cgroup_is_populated with cpuset_is_populated in the partition_is_populated function. Cc: stable@vger.kernel.org # 6.1+ Fixes: b1bcaed1e39a ("cpuset: Treat cpusets in attaching as populated") Cc: Waiman Long Cc: Tejun Heo Signed-off-by: Chen Ridong Signed-off-by: Greg Kroah-Hartman

ring-buffer: Avoid softlockup in ring_buffer_resize() during memory free

2026-02-11T12:40:21Z

[ Upstream commit 6435ffd6c7fcba330dfa91c58dc30aed2df3d0bf ] When user resize all trace ring buffer through file 'buffer_size_kb', then in ring_buffer_resize(), kernel allocates buffer pages for each cpu in a loop. If the kernel preemption model is PREEMPT_NONE and there are many cpus and there are many buffer pages to be freed, it may not give up cpu for a long time and finally cause a softlockup. To avoid it, call cond_resched() after each cpu buffer free as Commit f6bd2c92488c ("ring-buffer: Avoid softlockup in ring_buffer_resize()") does. Detailed call trace as follow: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 24-....: (14837 ticks this GP) idle=521c/1/0x4000000000000000 softirq=230597/230597 fqs=5329 rcu: (t=15004 jiffies g=26003221 q=211022 ncpus=96) CPU: 24 UID: 0 PID: 11253 Comm: bash Kdump: loaded Tainted: G EL 6.18.2+ #278 NONE pc : arch_local_irq_restore+0x8/0x20 arch_local_irq_restore+0x8/0x20 (P) free_frozen_page_commit+0x28c/0x3b0 __free_frozen_pages+0x1c0/0x678 ___free_pages+0xc0/0xe0 free_pages+0x3c/0x50 ring_buffer_resize.part.0+0x6a8/0x880 ring_buffer_resize+0x3c/0x58 __tracing_resize_ring_buffer.part.0+0x34/0xd8 tracing_resize_ring_buffer+0x8c/0xd0 tracing_entries_write+0x74/0xd8 vfs_write+0xcc/0x288 ksys_write+0x74/0x118 __arm64_sys_write+0x24/0x38 Cc: Link: https://patch.msgid.link/20251228065008.2396573-1-mawupeng1@huawei.com Signed-off-by: Wupeng Ma Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin

tracing: Fix ftrace event field alignments

2026-02-11T12:40:18Z

[ Upstream commit 033c55fe2e326bea022c3cc5178ecf3e0e459b82 ] The fields of ftrace specific events (events used to save ftrace internal events like function traces and trace_printk) are generated similarly to how normal trace event fields are generated. That is, the fields are added to a trace_events_fields array that saves the name, offset, size, alignment and signness of the field. It is used to produce the output in the format file in tracefs so that tooling knows how to parse the binary data of the trace events. The issue is that some of the ftrace event structures are packed. The function graph exit event structures are one of them. The 64 bit calltime and rettime fields end up 4 byte aligned, but the algorithm to show to userspace shows them as 8 byte aligned. The macros that create the ftrace events has one for embedded structure fields. There's two macros for theses fields: __field_desc() and __field_packed() The difference of the latter macro is that it treats the field as packed. Rename that field to __field_desc_packed() and create replace the __field_packed() to be a normal field that is packed and have the calltime and rettime use those. This showed up on 32bit architectures for function graph time fields. It had: ~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format [..] field:unsigned long func; offset:8; size:4; signed:0; field:unsigned int depth; offset:12; size:4; signed:0; field:unsigned int overrun; offset:16; size:4; signed:0; field:unsigned long long calltime; offset:24; size:8; signed:0; field:unsigned long long rettime; offset:32; size:8; signed:0; Notice that overrun is at offset 16 with size 4, where in the structure calltime is at offset 20 (16 + 4), but it shows the offset at 24. That's because it used the alignment of unsigned long long when used as a declaration and not as a member of a structure where it would be aligned by word size (in this case 4). By using the proper structure alignment, the format has it at the correct offset: ~# cat /sys/kernel/tracing/events/ftrace/funcgraph_exit/format [..] field:unsigned long func; offset:8; size:4; signed:0; field:unsigned int depth; offset:12; size:4; signed:0; field:unsigned int overrun; offset:16; size:4; signed:0; field:unsigned long long calltime; offset:20; size:8; signed:0; field:unsigned long long rettime; offset:28; size:8; signed:0; Cc: stable@vger.kernel.org Cc: Mathieu Desnoyers Cc: Mark Rutland Acked-by: Masami Hiramatsu (Google) Reported-by: "jempty.liang" Link: https://patch.msgid.link/20260204113628.53faec78@gandalf.local.home Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Closes: https://lore.kernel.org/all/20260130015740.212343-1-imntjempty@163.com/ Closes: https://lore.kernel.org/all/20260202123342.2544795-1-imntjempty@163.com/ Signed-off-by: Steven Rostedt (Google) [ adapted field types and macro arguments ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

perf: sched: Fix perf crash with new is_user_task() helper

2026-02-06T15:55:50Z

[ Upstream commit 76ed27608f7dd235b727ebbb12163438c2fbb617 ] In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ Fixes: 90942f9fac05 ("perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of current->mm == NULL") Closes: https://lore.kernel.org/all/0d877e6f-41a7-4724-875d-0b0a27b8a545@roeck-us.net/ Reported-by: Guenter Roeck Signed-off-by: Steven Rostedt (Google) Signed-off-by: Peter Zijlstra (Intel) Tested-by: Guenter Roeck Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260129102821.46484722@gandalf.local.home Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

perf: Simplify get_perf_callchain() user logic

2026-02-06T15:55:50Z

[ Upstream commit d77e3319e31098a6cb97b7ce4e71ba676e327fd7 ] Simplify the get_perf_callchain() user logic a bit. task_pt_regs() should never be NULL. Signed-off-by: Josh Poimboeuf Signed-off-by: Steven Rostedt (Google) Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://lore.kernel.org/r/20250820180428.760066227@kernel.org Stable-dep-of: 76ed27608f7d ("perf: sched: Fix perf crash with new is_user_task() helper") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

cgroup: Fix kernfs_node UAF in css_free_rwork_fn

2026-02-06T15:55:49Z

This fix patch is not upstream, and is applicable only to kernels 6.10 (where the cgroup_rstat_lock tracepoint was added) through 6.15 after which commit 5da3bfa029d6 ("cgroup: use separate rstat trees for each subsystem") reordered cgroup_rstat_flush as part of a new feature addition and inadvertently fixed this UAF. css_free_rwork_fn first releases the last reference on the cgroup's kernfs_node, and then calls cgroup_rstat_exit which attempts to use it in the cgroup_rstat_lock tracepoint: kernfs_put(cgrp->kn); cgroup_rstat_exit cgroup_rstat_flush __cgroup_rstat_lock trace_cgroup_rstat_locked: TP_fast_assign( __entry->root = cgrp->root->hierarchy_id; __entry->id = cgroup_id(cgrp); Where cgroup_id is: static inline u64 cgroup_id(const struct cgroup *cgrp) { return cgrp->kn->id; } Fix this by reordering the kernfs_put after cgroup_rstat_exit. [78782.605161][ T9861] BUG: KASAN: slab-use-after-free in trace_event_raw_event_cgroup_rstat+0x110/0x1dc [78782.605182][ T9861] Read of size 8 at addr ffffff890270e610 by task kworker/6:1/9861 [78782.605199][ T9861] CPU: 6 UID: 0 PID: 9861 Comm: kworker/6:1 Tainted: G W OE 6.12.23-android16-5-gabaf21382e8f-4k #1 0308449da8ad70d2d3649ae989c1d02f0fbf562c [78782.605220][ T9861] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE [78782.605226][ T9861] Hardware name: Qualcomm Technologies, Inc. Alor QRD + WCN7750 WLAN + Kundu PD2536F_EX (DT) [78782.605235][ T9861] Workqueue: cgroup_destroy css_free_rwork_fn [78782.605251][ T9861] Call trace: [78782.605254][ T9861] dump_backtrace+0x120/0x170 [78782.605267][ T9861] show_stack+0x2c/0x40 [78782.605276][ T9861] dump_stack_lvl+0x84/0xb4 [78782.605286][ T9861] print_report+0x144/0x7a4 [78782.605301][ T9861] kasan_report+0xe0/0x140 [78782.605315][ T9861] __asan_load8+0x98/0xa0 [78782.605329][ T9861] trace_event_raw_event_cgroup_rstat+0x110/0x1dc [78782.605339][ T9861] __traceiter_cgroup_rstat_locked+0x78/0xc4 [78782.605355][ T9861] __cgroup_rstat_lock+0xe8/0x1dc [78782.605368][ T9861] cgroup_rstat_flush_locked+0x7dc/0xaec [78782.605383][ T9861] cgroup_rstat_flush+0x34/0x108 [78782.605396][ T9861] cgroup_rstat_exit+0x2c/0x120 [78782.605409][ T9861] css_free_rwork_fn+0x504/0xa18 [78782.605421][ T9861] process_scheduled_works+0x378/0x8e0 [78782.605435][ T9861] worker_thread+0x5a8/0x77c [78782.605446][ T9861] kthread+0x1c4/0x270 [78782.605455][ T9861] ret_from_fork+0x10/0x20 [78782.605470][ T9861] Allocated by task 2864 on cpu 7 at 78781.564561s: [78782.605467][ C5] ENHANCE: rpm_suspend+0x93c/0xafc: 0:0:0:0 ret=0 [78782.605481][ T9861] kasan_save_track+0x44/0x9c [78782.605497][ T9861] kasan_save_alloc_info+0x40/0x54 [78782.605507][ T9861] __kasan_slab_alloc+0x70/0x8c [78782.605521][ T9861] kmem_cache_alloc_noprof+0x1a0/0x428 [78782.605534][ T9861] __kernfs_new_node+0xd4/0x3e4 [78782.605545][ T9861] kernfs_new_node+0xbc/0x168 [78782.605554][ T9861] kernfs_create_dir_ns+0x58/0xe8 [78782.605565][ T9861] cgroup_mkdir+0x25c/0xc9c [78782.605576][ T9861] kernfs_iop_mkdir+0x130/0x214 [78782.605586][ T9861] vfs_mkdir+0x290/0x388 [78782.605599][ T9861] do_mkdirat+0xfc/0x27c [78782.605612][ T9861] __arm64_sys_mkdirat+0x5c/0x78 [78782.605625][ T9861] invoke_syscall+0x90/0x1e8 [78782.605634][ T9861] el0_svc_common+0x134/0x168 [78782.605643][ T9861] do_el0_svc+0x34/0x44 [78782.605652][ T9861] el0_svc+0x38/0x84 [78782.605667][ T9861] el0t_64_sync_handler+0x70/0xbc [78782.605681][ T9861] el0t_64_sync+0x19c/0x1a0 [78782.605695][ T9861] Freed by task 69 on cpu 1 at 78782.573275s: [78782.605705][ T9861] kasan_save_track+0x44/0x9c [78782.605719][ T9861] kasan_save_free_info+0x54/0x70 [78782.605729][ T9861] __kasan_slab_free+0x68/0x8c [78782.605743][ T9861] kmem_cache_free+0x118/0x488 [78782.605755][ T9861] kernfs_free_rcu+0xa0/0xb8 [78782.605765][ T9861] rcu_do_batch+0x324/0xaa0 [78782.605775][ T9861] rcu_nocb_cb_kthread+0x388/0x690 [78782.605785][ T9861] kthread+0x1c4/0x270 [78782.605794][ T9861] ret_from_fork+0x10/0x20 [78782.605809][ T9861] Last potentially related work creation: [78782.605814][ T9861] kasan_save_stack+0x40/0x70 [78782.605829][ T9861] __kasan_record_aux_stack+0xb0/0xcc [78782.605839][ T9861] kasan_record_aux_stack_noalloc+0x14/0x24 [78782.605849][ T9861] __call_rcu_common+0x54/0x390 [78782.605863][ T9861] call_rcu+0x18/0x28 [78782.605875][ T9861] kernfs_put+0x17c/0x28c [78782.605884][ T9861] css_free_rwork_fn+0x4f4/0xa18 [78782.605897][ T9861] process_scheduled_works+0x378/0x8e0 [78782.605910][ T9861] worker_thread+0x5a8/0x77c [78782.605923][ T9861] kthread+0x1c4/0x270 [78782.605932][ T9861] ret_from_fork+0x10/0x20 [78782.605947][ T9861] The buggy address belongs to the object at ffffff890270e5b0 [78782.605947][ T9861] which belongs to the cache kernfs_node_cache of size 144 [78782.605957][ T9861] The buggy address is located 96 bytes inside of [78782.605957][ T9861] freed 144-byte region [ffffff890270e5b0, ffffff890270e640) Fixes: fc29e04ae1ad ("cgroup/rstat: add cgroup_rstat_lock helpers and tracepoints") Signed-off-by: T.J. Mercier Acked-by: Michal Koutný Signed-off-by: Greg Kroah-Hartman

sched/deadline: Fix 'stuck' dl_server

2026-02-06T15:55:44Z

[ Upstream commit 115135422562e2f791e98a6f55ec57b2da3b3a95 ] Andrea reported the dl_server getting stuck for him. He tracked it down to a state where dl_server_start() saw dl_defer_running==1, but the dl_server's job is no longer valid at the time of dl_server_start(). In the state diagram this corresponds to [4] D->A (or dl_server_stop() due to no more runnable tasks) followed by [1], which in case of a lapsed deadline must then be A->B. Now our A has dl_defer_running==1, while B demands dl_defer_running==0, therefore it must get cleared when the CBS wakeup rules demand a replenish. Fixes: a110a81c52a9 ("sched/deadline: Deferrable dl server") Reported-by: Andrea Righi arighi@nvidia.com Signed-off-by: Peter Zijlstra (Intel) Acked-by: Juri Lelli Tested-by: Andrea Righi arighi@nvidia.com Link: https://lkml.kernel.org/r/20260123161645.2181752-1-arighi@nvidia.com Link: https://patch.msgid.link/20260130124100.GC1079264@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin

sched/deadline: Document dl_server

2026-02-06T15:55:44Z

[ Upstream commit 2614069c5912e9d6f1f57c262face1b368fb8c93 ] Place the notes that resulted from going through the dl_server code in a comment. Signed-off-by: Peter Zijlstra (Intel) Stable-dep-of: 115135422562 ("sched/deadline: Fix 'stuck' dl_server") Signed-off-by: Sasha Levin

dma/pool: distinguish between missing and exhausted atomic pools

2026-02-06T15:55:44Z

[ Upstream commit 56c430c7f06d838fe3b2077dbbc4cc0bf992312b ] Currently, dma_alloc_from_pool() unconditionally warns and dumps a stack trace when an allocation fails, with the message "Failed to get suitable pool". This conflates two distinct failure modes: 1. Configuration error: No atomic pool is available for the requested DMA mask (a fundamental system setup issue) 2. Resource Exhaustion: A suitable pool exists but is currently full (a recoverable runtime state) This lack of distinction prevents drivers from using __GFP_NOWARN to suppress error messages during temporary pressure spikes, such as when awaiting synchronous reclaim of descriptors. Refactor the error handling to distinguish these cases: - If no suitable pool is found, keep the unconditional WARN regarding the missing pool. - If a pool was found but is exhausted, respect __GFP_NOWARN and update the warning message to explicitly state "DMA pool exhausted". Fixes: 9420139f516d ("dma-pool: fix coherent pool allocations for IOMMU mappings") Signed-off-by: Sai Sree Kartheek Adivi Reviewed-by: Robin Murphy Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20260128133554.3056582-1-s-adivi@ti.com Signed-off-by: Sasha Levin

sched_ext: Fix possible deadlock in the deferred_irq_workfn()

2026-01-30T09:28:48Z

[ Upstream commit a257e974210320ede524f340ffe16bf4bf0dda1e ] For PREEMPT_RT=y kernels, the deferred_irq_workfn() is executed in the per-cpu irq_work/* task context and not disable-irq, if the rq returned by container_of() is current CPU's rq, the following scenarios may occur: lock(&rq->__lock); lock(&rq->__lock); This commit use IRQ_WORK_INIT_HARD() to replace init_irq_work() to initialize rq->scx.deferred_irq_work, make the deferred_irq_workfn() is always invoked in hard-irq context. Signed-off-by: Zqiang Signed-off-by: Tejun Heo Signed-off-by: Chen Yu Signed-off-by: Greg Kroah-Hartman