summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2026-09-15sched_ext: Maintain an online cid mask in the scheduler arenagraftedTejun Heo
Schedulers on the default cid mapping treat [0, nr_online_cids) as the online set and restart on hotplug. Schedulers that install their own mapping with scx_bpf_cid_override() have no way to learn which cids are online: the count no longer identifies members and the CPU-form cpumask is unusable from cid programs. This is an obvious hole in the cid API. Add scx_bpf_online_cmask(), a kernel-maintained cmask in the scheduler's arena, allocated alongside the per-CPU scratch masks and populated after the cid mapping is finalized and before ops.init(), for child schedulers too. The pointer stays valid through ops.exit() with no reference to take. It is the arena offset as a void pointer, the same form struct_ops arena arguments arrive in. The verifier types the void return as a scalar for the program's arena cast. The mask follows the SCX hotplug notifications: seeded from cpu_active_mask and updated before ops.cid_online/offline() runs, so it lags cpu_online_mask only inside a hotplug transition. Updates walk the scheduler list under the lock that also serializes unlinking. Reads are live, not atomic snapshots. Root initialization excludes hotplug. v2: Reworded the getter kerneldoc (Andrea Righi). Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-09-15dmaengine: mmp_pdma: fix wrong sg length in mmp_pdma_prep_slave_sg()Baineng Shou
In mmp_pdma_prep_slave_sg(), for_each_sg() iterates the scatterlist putting each entry into 'sg', but the entry length is read from 'sgl' (the list head) instead of 'sg' (the current entry): for_each_sg(sgl, sg, sg_len, i) { addr = sg_dma_address(sg); avail = sg_dma_len(sgl); /* should be 'sg' */ Consequently 'avail' is always the length of the first entry. For multi-sg lists this causes out-of-bounds reads when a later entry is shorter than the first, and silent data loss when it is longer. Single-sg or uniformly-sized lists happen to mask the issue. Fixes: c8acd6aa6bed3 ("dmaengine: mmp-pdma support") Signed-off-by: Baineng Shou <shoubaineng@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260910021652.1296640-1-shoubaineng@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-15clk: spacemit: k3: add CPU PLL rate tablesTroy Mitchell
The K3 CPU PLL rate tables currently describe only one rate per PLL, although the hardware supports a wider range. PLL3 and PLL4 support rates from 1.05 to 2.4 GHz, while PLL5 and PLL8 support rates from 1.05 to 2 GHz. Populate the tables with every supported rate in 50 MHz steps. Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree") Cc: stable@vger.kernel.org # 7.0+ Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Yixun Lan <dlan@kernel.org> Link: https://patch.msgid.link/20260907-k3-pll5-pll8-1800mhz-v5-1-5cc96d716b0a@linux.spacemit.com Signed-off-by: Yixun Lan <dlan@kernel.org>
2026-09-14cgroup: Avoid iteration of dying tasks with zero refcountMichal Koutný
The commit 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") extended the lifetime of tasks on the dying_tasks list. The iterators have provision to go through dying_tasks because of dying threadgroup leaders or explicit CSS_TASK_ITER_WITH_DEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgroup_task_release()/put_task_struct_rcu_user()). The tasks after cgroup_task_release() and before cgroup_task_free() are subject to race when they may or may not have ->usage count > 0. The race window is between css_task_iter_next() invocations when css_set_lock is released and we may arrive at a new ->task_pos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, __put_task_struct_rcu_cb() is already imminent and the returned task_struct would could be used after free.) As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration. The repeat: loop in css_task_iter_advance() doesn't consider ->usage count, so add a new loop to css_task_iter_next() to skip de-used tasks on the dying_list. Rough illustration of the possible race R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgroup_task_dead(L) css_set_skip_task_iters() // skips only cset->tasks list_add_tail(&L->cg_list, &cset->dying_tasks) css_task_iter_next() take css_set_lock css_task_iter_advance() leader && signal->live != 0 => it->task_pos = &L->cg_list release css_set_lock T exits --signal->live == 0 cgroup_task_dead(T) // css_set_lock release_task(T) cgroup_task_release(T) release_task(L) // zap_leader cgroup_task_release(L) put_task_struct_rcu_user(L) ...RCU... put_task_struct(L) L->usage = 0 /* L still on dying_tasks */ ...RCU... __put_task_struct(L) css_task_iter_next() // another iteration take css_set_lock it->task_pos = &L->cg_list get_task_struct(L) => addition on 0 drop css_set_lock cgroup_task_free(L) css_set_skip_task_iters() // dying skip comes too late free_task(L) cgroup_procs_show() task_pid_vnr(L) Fixes: 260fbcb92bbea ("cgroup: Move dying_tasks cleanup from cgroup_task_release() to cgroup_task_free()") Cc: stable@vger.kernel.org # v6.19+ Link: https://lists.debian.org/debian-kernel/2026/08/msg00220.html Reported-by: Noah Elias Feldt <N.Feldt@mittwald.de> Reported-by: Salvatore Bonaccorso <carnil@debian.org> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Michal Koutný <mkoutny@suse.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-09-14thunderbolt: Reject oversized XDomain properties responsesDaehyeon Ko
tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer. The XDomain length field is six bits wide, however, and a malicious peer can set it to 63. After the fixed response fields are subtracted, the driver treats this as 48 data dwords. Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len. If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read. Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length. Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block. Fixes: d1ff70241a27 ("thunderbolt: Add support for XDomain discovery protocol") Cc: stable@vger.kernel.org Assisted-by: LLM Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-09-13Input: hp_sdc - shut down kicker timer on module exitRunyu Xiao
hp_sdc_kicker() rearms hp_sdc.kicker with mod_timer() after scheduling the tasklet. The module exit path uses timer_delete_sync(). That waits for a callback already running but can still leave the timer rearmed. A callback can therefore leave the timer pending while hp_sdc_exit() tears down the driver, allowing timer activity to access dismantled driver state. Use timer_shutdown_sync() for final teardown. It waits for a running callback and prevents rearming after module exit begins. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Assisted-by: Codex:GPT-5 Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Acked-by: Helge Deller <deller@gmx.de> Link: https://patch.msgid.link/20260902154004.3595416-1-runyu.xiao@seu.edu.cn Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: xpad - add support for Victrix Pro BFG ControllerErich Sartison
The controller doesn't currently work via USB-cable. Signed-off-by: Erich Sartison <byt.es@mailbox.org> Link: https://patch.msgid.link/20260903103137.630170-1-byt.es@mailbox.org Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13Input: tsc2007 - read "ti,poll-period" as u32graftedRob Herring (Arm)
The "ti,poll-period" property is documented as a normal uint32 cell. The driver used a u64 helper, which makes the helper type disagree with the schema even though the stored value is still small. Read "ti,poll-period" with the u32 helper matching the documented DT cell size. Assisted-by: Codex:gpt-5-5 Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260831194352.1185860-1-robh@kernel.org Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2026-09-13objtool: Validate disassembler headers in libopcodes probegraftedUlises Mendez Martinez
commit 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") tested for libopcodes availability by linking a test snippet with a forward declaration of disassemble_init_for_target(). However, testing symbol linkage with an extern declaration only verifies the presence of the library (.so/.a) and bypasses checking for development headers (binutils-dev). On systems where libopcodes is present without development headers installed, the probe succeeds, enabling BUILD_DISAS. Subsequent compilation of objtool then fails: fatal error: 'bfd.h' file not found 113 | #include <bfd.h> Additionally, the probe invokes $(HOSTCC) without $(HOSTCFLAGS), ignoring any sysroot or include flags specified for the host compiler. Fix this by including <bfd.h> and <dis-asm.h> directly in the test snippet, passing $(HOSTCFLAGS) so host compiler options are respected, and defining PACKAGE="objtool" to satisfy the configuration check in <bfd.h>. Fixes: 3f2de814c059 ("objtool: Fix libopcodes linking with static libraries") Fixes: 436326bc525d ("objtool: fix build failure due to missing libopcodes check") Reported-by: Alice Ryhl <aliceryhl@google.com> Assisted-by: Antigravity:Gemini-Next Signed-off-by: Ulises Mendez Martinez <umendez@google.com> Link: https://patch.msgid.link/20260904150710.2997558-1-umendez@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
2026-09-13Linux 7.3-rc3v7.3-rc3Linus Torvalds
2026-09-13Merge tag 'trace-v7.3-rc2' of ↵graftedLinus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Don't destroy user event fields when removal fails User event fields are destroyed before the event is removed from visibility. But that can fail leaving the still visible event with no fields. Move the destroying of the fields to after the event is successfully removed from visibility. - Initialize function graph state is fork before calling copy_exec_state() For non-CLONE_VM forks, copy_exec_state() allocates a new task_exec_state. If that allocation fails, ftrace_graph_exit_task() will free the tasks ret_stack pointer. Since that pointer is still using the parent's ret_stack, it mistakenly frees the parent's pointer too. Call ftrace_graph_init() on the task first which will NULL out the new tasks's ret_stack and if the copy fails, it will not free anything. - Remove FGRAPH_MAX_INDEX The macro FGRAPH_MAX_INDEX was added but never used. Remove it. - Save ent_size in function graph printing of nested functions The function graph tracer needs to look at the next event to see if the next event is the return of the current function entry. If it is, it prints a single line: ktime_get(); Otherwise it prints it like a nested function: tick_nohz_irq_exit() { ktime_get(); kcpustat_irq_exit(); } In order to look at the next event, it must save the current event so that it has the information to print from it. It saves the event in the iterator descriptor called "ent". What it doesn't save is the ent_size of the event which is now used to know if the function graph arguments are to be printed. The peek doesn't save the size so the size used happens to be that of the size of the last event that was seen. Save the entry event size in the iterator descriptor so that the correct size is used. - Fix several errors with freeing data in the histogram code The histogram code had a lot of leaked or or incorrect accounting when failures happen. Correct them. - Fix histogram regression of .percent and .graph modifiers Up until 6.3 histogram values could have "percent" or "graph" modifiers that changed how they were printed. But a change that added restricting histograms values from being strings, stack traces and other modifiers inadvertently prevented them from using the percent and graph modifiers, which were legal use cases for values. Put back the percent and graph modifiers. - Fix various typos in the comments - Set the trace_clock before initializing a histogram with clock argument The histogram API allows the user to specific which trace clock to use via a "clock=" string. The histogram is set up first before the clock is checked. If the passed in clock is not valid, it exits without fully fixing up the histogram leaving it on the list and a use-after-free can trigger. Update the clock argument first and if it fails then exit gracefully before the histogram trigger is placed on any lists. - Restore :mod: trailer after parsing in ftrace_set_clr_event The function ftrace_set_clr_event() modifies the parse string and needs to put it back to what was passed in. It searches for ":mod:" via a strsep() but fails to put back the first ':' in the string. Add back the ':' in the passed in string. - Take trace_array reference when opening a tracer options file The options files are dynamically created and some tracers add their own options. When a tracer adds their own list of options, the trace_array holding them has an array to hold the list of options for each tracer. This array increases in size via a krealloc(), and the new entry gets a newly allocated array to hold the options of the new tracer being added. The element in each entry of the tracer's option array holds a pointer back to the trace_array, a pointer to the tracer it is associated to, a pointer to the flags of the option. The issue is that these arrays are freed when the trace_array is freed when its instance it represents is removed from the instances directory. There's a race that an open of one of these options files can happen when the instance is being removed. Add a new helper function to be called by the open function of the options file to iterate all existing trace_arrays under a lock and find the one that has the given option element in one of it's tracer arrays. If found, then update the associated trace_array's reference counter to keep it from being freed. If not found, have the open call return -ENODEV. - Disable interrupts when acquiring the lock in rb_wake_up_waiters() The function rb_wake_up_waiters() assumes it will be called in interrupt context and does not disable irqs when taking cpu_buffer->reader_lock, which can be called in hard interrupt context. The issue is in PREEMPT_RT, this function is called in thread context leaving this lock open to a deadlock. Take the lock with interrupts disabled. - Use rcu_assign_pointer() for tmp_ops filter hash The tmp_ops used in update_ftrace_direct_mod() assigns its filter_hash field directly, but that field is annotated as __rcu and sparse complains. Assign it with rcu_assign_pointer() - Fix use-after-free in enable_trigger_private_data_free() The trace_event_call is accessed through the event_trigger_data's trace_event_file pointer to put the trace_event_call on freeing. The issue is that the trace_event_file data may have been freed already causing a use-after-free. Add a field to the event_trigger_data that points directly to the trace_event_call so that it can decrement its reference directly without needing to go through the trace_event_file. - Fix accounting of buffer data remote headers trace_buffer_desc_size() and trace_remote_alloc_buffer() undercount the number of pages is needed for the asked for size as it doesn't take into account the meta data on each page. Add a helper function to do the calculation properly and use that in these functions. - Catch nr_page_va overflow in ring_buffer_desc sizing The number of pages per remote ring buffer is capped by ring_buffer_desc::nr_page_va (32 bits). A buffer_size large enough to overflow that field would silently allocate a descriptor smaller than what was asked for. - Do not resize the subbuf order if any per_cpu buffer is disabled The mmapping of ring buffers disables resizing the subbuffers, but it is done per-cpu whereas the subbuf size change is done for all the per_cpu buffers under the buffer->mutex. It could change the size of some while the mapping is happening on others. Have the resize of the subbuf order check all the per_cpu buffers under the lock to see if any of them is disabled before starting and causing an inconsistency between buffers that are being mapped. * tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: (25 commits) ring-buffer: Check resize_disabled before publishing the new subbuf order tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing tracing/remotes: Account for ring buffer page header in size calculation tracing: Don't dereference trace_event_file in deferred trigger free ftrace: Use rcu_assign_pointer() for tmp_ops filter hash ring-buffer: Acquire the lock with irqsave in rb_wake_up_waiters() tracing: Take trace_array reference when opening a tracer options file tracing: Fix ring_buffer_read_page_size() kernel-doc tracing: Restore :mod: trailer after parsing in ftrace_set_clr_event() tracing: Fix memory corruption from a "STACKTRACE" histogram key tracing: Fix memory corruption from the histogram stacktrace modifier tracing: Undo the registration when enabling the histogram trigger fails tracing: Take the reference before publishing the named histogram trigger tracing: Set the trace clock before registering the histogram trigger tracing: Fix typo "preceeded" in comment tracing: Fix typo "availabe" in comment tracing: Let histogram values keep the percent and graph modifiers tracing: Keep the entry count when the histogram stats allocation fails tracing: Free histogram the field rejected for a bad modifier tracing: Free histogram the var ref when its initialization fails ...
2026-09-13phy: mediatek: phy-mtk-hdmi-mt8195: Fix TMDS clk bit ratio settingAngeloGioacchino Del Regno
The comment in the mtk_phy_tmds_clk_ratio() function clearly and correctly explains that the TMDS ratio has to be 1/10 for data rates under 3.4Gbps, and 1/40 over that. Unfortunately though, the TXC_DIV register setting was wrong, as in value 3 means to divide by 8 and, in order to achieve the in spec 1/40 (tmds) data rate, this has to divide by 4 instead! Add definitions for the TXC_DIV register values clearly explaining the meanings (DIV2, DIV4, DIV8), and program the correct, DIV 4, value to the register in mtk_phy_tmds_clk_ratio(). This fixes out of spec clocking and, with this change, SoCs using the MT8195 class HDMI PHYs can now successfully be configured to output 3840x2160@60Hz over HDMI. Fixes: 45810d486bb4 ("phy: mediatek: add support for phy-mtk-hdmi-mt8195") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260911074015.9994-3-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-13phy: mediatek: phy-mtk-hdmi-mt8195: Fix PLL calc divisor overflowAngeloGioacchino Del Regno
When trying to calculate a PLL rate for target display resolutions above 2560x1440, 24bpp, 30Hz, the pixel clock value will be more than 32-bits long but the division to finally calculate the digital clock divider is being done with div_u64(), which expects a 32bit unsigned divisor. Fix the overflow by using div64_u64() instead. Fixes: 9d9ff3d2a4a5 ("phy: mediatek: hdmi: mt8195: fix wrong pll calculus") Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260911074015.9994-2-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-13phy: renesas: rcar-gen3-usb2: Avoid long delay in atomic contextClaudiu Beznea
The OTG PHY initialization sequence needs to wait for 20 ms at a specific step, as described in commit 72c0339c115b ("phy: renesas: rcar-gen3-usb2: follow the hardware manual procedure"). Commit 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") tried to address various problems in the rcar-gen3-usb2 driver and converted the mutex protecting HW register accesses to a spin lock, leaving, however, a long delay in the critical section protected by the spin lock. This may become a problem, especially on RT kernels. To address this, release the spin lock before sleeping for 20 ms as required by the HW manual and reacquire it afterwards. To avoid other threads entering the critical section and configuring the HW while the software is waiting for the OTG initialization to complete, introduce the otg_initializing variable alongside the otg_init_done wait queue. Any other thread trying to configure the HW while the OTG PHY initialization is in progress waits for the wait queue instead of immediately returning errors to PHY users. The IRQs were also disabled while waiting for the OTG PHY initialization to complete, as the interrupt handler may also apply HW settings. The OTG can only be initialized once. It is initialized by the first PHY that calls struct phy_ops::rcar_gen3_phy_usb2_init(). To avoid failures when multiple PHYs call struct phy_ops::rcar_gen3_phy_usb2_init() simultaneously, and the PHY responsible for initializing the OTG either fails or deinit quiqly and another PHY takes over the PHY init role), the code waiting for the channel->otg_init_done wait queue retries up to NUM_OF_PHYS times. Fixes: 55a387ebb921 ("phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver data") Cc: stable@vger.kernel.org Reported-by: Pavel Machek <pavel@nabladev.com> Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Closes: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Link: https://lore.kernel.org/all/afhkX2Ys2BG1gnqy@duo.ucw.cz Link: https://patch.msgid.link/20260716183246.3183877-1-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-11clk: ti: composite: resolve parent clocks by name againAndreas Kemnade
Trying to resolve them by DT index causes massive havoc on OMAP3, Clocks around the timers used as a system clocksource are not properly resolved causing ealy boot failures. The problem seems to be that parents must be resolved by looking into the clocks property of the component node marked with "ti,composite-mux-clock", with the switch to dt index, that node was not used anymore. It was used by the of_clk_parent_fill() call. To a lesser extent also OMAP4/5 boards are affected. Since this patch was introduced just because of a cleanup request and not to solve the actual problem (https://lore.kernel.org/linux-omap/alkZmw-XmnCOZfOD@redhat.com/) just revert it. Cleanup needs really more thought here. The similar change to the TI mux clock, which solves a problem on the AM3 platform, seems to be harmless. So just revert commit fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name") for now. Fixes: fe3dd92ac54a ("clk: ti: composite: resolve parent clocks by DT index, not by name") Reviewed-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Brian Masney <bmasney@redhat.com>
2026-09-11debugfs: don't warn about uninitialized debugfs for an error parentMikhail Gavrilov
Since commit c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") every boot with CONFIG_REF_TRACKER=y and CONFIG_DEBUG_FS=y prints two errors before the root filesystem is mounted: debugfs: Unable to create file 'net_refcnt@(____ptrval____)', debugfs is not initialized yet debugfs: Unable to create file 'net_notrefcnt@(____ptrval____)', debugfs is not initialized yet Nothing is actually wrong. Both files show up under /sys/kernel/debug/ref_tracker/ once the system is up. The kernel is reporting an error for a condition the caller has already accounted for. net_ns_init() runs directly from start_kernel(), before any initcall, and calls ref_tracker_dir_init() for init_net's two trackers. debugfs_init() is a core_initcall, so debugfs cannot possibly be up at that point. That is by design: ref_tracker_dir_debugfs() is documented as safe to call again later, and net/core/net_namespace.c has a late_initcall() that re-registers both directories once debugfs exists. ref_tracker also states that intent to debugfs. ref_tracker_debug_dir is initialised to ERR_PTR(-ENOENT) and only gets a real dentry in a late_initcall, so the early call hands debugfs_create_file() a parent that is already an error. debugfs_start_creating() honours that and returns the parent error, but only after the new pr_err() has fired. Move the IS_ERR(parent) check above the debugfs_initialized() test. A caller passing an error parent is propagating an earlier failure, which is the pattern debugfs documents and which the warning is not aimed at. A caller passing a valid or NULL parent too early - the case the warning was added for - still gets it. One behaviour change: an early caller with an error parent now gets PTR_ERR(parent) back instead of -ENOENT. All callers of these interfaces are documented to ignore the return value. Fixes: c3a280ff728a ("debugfs: warn if file creation failed due to uninitialized debugfs") Link: https://lore.kernel.org/all/6d1dc775f7d5e754d734907514534054f682bac5.1781171918.git.yk@y-koj.net/ Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: Yohei Kojima <yk@y-koj.net> Link: https://patch.msgid.link/20260903115135.63210-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-09-11Merge tag 'iio-fixes-for-7.3a' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: IIO: 1st set of fixes for the 7.3 cycle. A couple of core fixes, the rest usual mix of driver issues that surfaced from merge window until now. core - buffer: Ensure that when using the iio_push_to_buffers_with_ts_unaligned() that the full buffer is zeroed. - trigger: Cancel reenable_work() before freeing the trigger that might be re-enabled. dma-buffer - Fix wrong sizing for a mapped sg_list. If an IOMMU was using a fused entry the mapping might walk off the end. adi,ade9000 - Wait for power up before requesting interrupts. - Fix overlap in scan index for current and voltage channels. - Ensure Phase C dip event included in IRQ1 handler. adi,adf4377 - Initialize all of a clk_init_data. adi,adis* - Ensure debugfs reads are finished before unbind. adi,axi-adc - Initialize mutex. adi,admv1013 - Ensure mutex is intialized before notifier that might use it is registered. - Fix wrong channel field used for read_raw. allwinner,sun4i - Drop a pm_runtime_put() when there was no get. - Ensure correct cleanup on driver probe fail due to any issues with the thermal zone. aspeed,adc, - Don't eat reset deassert errors. awinic,aw96103 - Make sure firmware length is validated rather than blindly trusting it. bosch,bmp280 - Fix out of bounds lookup of sampling frequency due to indexing based on elements in matrix rather than just the correct dimension. invensense,timestamp library - Ensure time estimate doesn't invert wrt to current time in a corner case occasionally seen. kionix,kx022a - Off by one in array boundary check. - Close a memory leak and state corruption in error path. maxim,max1363 - Sign extend bipolar values to ensure correct reporting to userspace. maxim,max30102 - Fix NULL dereference by checking there is data in the FIFO before trying to do anything with it. microchip,mcp47a1 - Ensure highest possible value actually settable. pulsed-light,lidar-lite - Don't leak the IIO device registration if runtime pm setup fails particularly as it was being freed. rockchip,saradc - Fix wrong fallback compatible for rv1106 that lead to trying to use too many channels (correct support will follow next merge window) rohm,bd79124 - Correct limit used for rising alarms. - Fix which registers related to limits are used in initialization. - Apply GPIO mask to allow subset of GPIOs to be toggled. - Add missing regmap error handling in a few places. - Ensures scale is read only. rohm,bm1390 - Don't silently eat a data read error. rohm,bu27034 - Don't silently eat error when reading gain. - Ensure we infinite delay doesn't happen on error. semtech,sx9324 - Fix wrong proximity channel resolution. sharp,gp2ap020a00f - Make sure to drain irq_work in remove path. st,vl5310x - Ensure direct mode is claimed for read_raw avoiding corruption of buffered accesses. vishay,vcnl3020 - Use write bits for ISR mask and ensure right event reported. vti,sca3000 - Fix up a condition check for the frequency divider. xilinx,xadc - Swap registration of cleanup of work with that of irq to ensure that no irqs can cause work that has been freed to be queued. x-powers,axp288 - Add bias override quirk for Haier HV103H. Fix because we used to always override then moved to trusting the firmware setup - which fixed some boards, but broke others. * tag 'iio-fixes-for-7.3a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (42 commits) iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handler iio: proximity: vl53l0x-i2c: claim direct mode for raw reads iio: dac: mcp47a1: Allow full-scale output iio: accel: kionix-kx022a: Prevent memory leak and fix state iio: light: rohm-bu27034: Fix infinite delay on error iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure iio: adc: sun4i-gpadc-iio: drop underflowing pm_runtime_put() calls iio: adc: axp288: Add TS bias override for Haier HV103H dt-bindings: iio: adc: rockchip-saradc: Fix RV1106 compatible dt-bindings: iio: adc: rockchip-saradc: Group single-entries into an enum list iio: inv_sensors: fix estimated value larger than interrupt timestamp iio: adc: aspeed: propagate reset deassert errors iio: buffer-dmaengine: fix sg entry iteration when building dma_vecs iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure iio: trigger: cancel reenable_work before freeing trigger iio: frequency: admv1013: fix wrong channel field used in admv1013_read_raw() iio: accel: sca3000: fix frequency divider condition check iio: admv1013: initialize callback mutex before registering notifier iio: gyro: adis16136: fix unprotected debugfs reads iio: imu: adis16400: fix unprotected debugfs reads ...
2026-09-10x86/amd_node: Fix PCI device reference counting in amd_smn_init()graftedYazen Ghannam
The local "root" pointer is a temporary variable used during the device search. Therefore, refcount related to the search iterators should be cleaned up after the search is complete. Use the __free() cleanup macro to ensure the refcount is decremented when the temporary pointer goes out of scope. Additionally, increment the refcount when caching a root pointer. This ensures the in-use refcount is separate from the temporary search refcounting. Finally, drop the redundant "root = NULL" before the second search loop. The pci_get_class() iterator always decrements the refcount of its "from" argument, so the first loop can only fall through with "root" already NULL. Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching") Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com Reported-by: Sashiko <sashiko-bot@kernel.org> Assisted-by: LLM Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Cc: <stable@kernel.org> Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com
2026-09-10dmaengine: xilinx_dma: Fix hardware buffer descriptor chain after cyclic DMAAlex Bereza
Using the DMA in cyclic mode modifies the hardware buffer descriptor chain in xilinx_dma_prep_dma_cyclic so that the last descriptor used by the cyclic transfer points back to the first descriptor, but it never restores the original descriptor ring. This breaks using non-cyclic mode after cyclic mode with an error like: xilinx-vdma 86000000.dma: Channel 00000000354d5c8d has errors 100, cdr 6de40000 tdr 6de40400 The only way to get out of this error state is to rebuild the hardware buffer descriptor ring by releasing and re-acquiring the channel. Fix using non-cyclic mode after cyclic mode by always restoring the original buffer descriptor ring in the same manner as it is set up by xilinx_dma_alloc_chan_resources(). Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza <alex@bereza.email> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com> Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-after-cyclic-mode-v1-1-1fe47e701d6c@bereza.email Link: https://patch.msgid.link/20260818-fix-hw-buf-desc-after-cyclic-mode-v2-1-530ff44c6a81@bereza.email Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-10dmaengine: pxa: fix double counting of the hw descriptorsSascha Hauer
pxad_alloc_desc() was converted from kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT) to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc itself - but only where the compiler has __builtin_counted_by_ref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nb_desc, which makes it come out doubled there and correct elsewhere. nb_desc is what pxad_free_desc() iterates over and what set_updater_desc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxad_free_desc() would free entries that were never allocated. Fixes: 69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20260817-dmaengine-pxa-v1-1-850c215c1196@pengutronix.de Link: https://patch.msgid.link/20260817-dmaengine-pxa-v2-1-f42ab0569a48@pengutronix.de Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-10dmaengine: sun6i: fix undefined behaviour in sun6i_dma_tx_statusChristian Lugnberg
sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual descriptor for a given cookie, before checking whether the pointer vd is NULL: vd = vchan_find_desc(&vchan->vc, cookie); txd = to_sun6i_desc(&vd->tx); /* vd may be NULL here */ if (vd) { for (lli = txd->v_lli; ...) vchan_find_desc() returns NULL when the descriptor has already been completed or is in-flight on a physical channel and no longer present in the virtual channel's descriptor list. When vd is NULL, to_sun6i_desc() is called unconditionally on &vd->tx before the NULL check, which is undefined behaviour. Move the call inside the if (vd) guard to ensure it is only reached with a valid pointer. vd = vchan_find_desc(&vchan->vc, cookie); if (vd) { struct sun6i_desc *txd = to_sun6i_desc(&vd->tx); for (lli = txd->v_lli; ...) Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg <christian.lugnberg@soundtrack.io> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260817135723.12807-3-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-10dmaengine: sun6i: fix non-atomic read of DMA position registersChristian Lugnberg
sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two separate readl() calls with no synchronisation between them: pos = readl(pchan->base + DMA_CHAN_LLI_ADDR); bytes = readl(pchan->base + DMA_CHAN_CUR_CNT); DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the remaining byte count for the *current* descriptor. If the DMA engine advances to the next LLI entry between the two reads, pos becomes stale: it still points to what was the next descriptor at the time of the first read, but that descriptor is now the current one and CUR_CNT reflects its initial (full) byte count. The subsequent virtual-chain walk starts one entry too early and accumulates an extra full period's worth of bytes into the residue estimate. Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and retrying if the value changed. This double-read pattern guarantees that both registers were sampled during the same descriptor interval. The cost is at most one extra readl() pair per call in the racy case, which occurs only at descriptor boundaries (~every 2 ms) and is negligible. Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Christian Lugnberg <christian.lugnberg@soundtrack.io> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260817135723.12807-2-christian.lugnberg@soundtrack.io Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-10dmaengine: xilinx_dma: Fix hardware buffer descriptor reuse orderAlex Bereza
xilinx_dma_alloc_chan_resources() builds a static ring of hardware buffer descriptors once and the driver uses this ring throughout the lifetime of a channel. This requires the allocation order of hardware buffer descriptors from chan->free_seg_list to stay in sync with the hardware buffer descriptor ring built at channel allocation time by returning oldest descriptors to chan->free_seg_list first. When chan->pending_list is not empty e.g. during xilinx_dma_terminate_all() the chan->free_seg_list and the order of the static hardware buffer descriptor ring get out of sync. Descriptors age in this order: pending -> active -> done. So freeing pending_list first returns the newest buffer descriptors to the chan->free_seg_list first and thus breaks the order required by the static hardware buffer descriptor ring. Then when the channel is reused, after a wrap around of the free_seg_list the DMA will find a hardware buffer descriptor with a length field that is still zeroed and stop with something like this: xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000 After this no more descriptors are completed and a consumer potentially blocks and waits forever. The only way to get out of this error state is to rebuild the static hardware buffer descriptor ring and the free_seg_list by releasing and re-acquiring the channel. Fix the order in which hardware buffer descriptors are returned to free_seg_list to ensure the mentioned requirement holds. Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario") Signed-off-by: Alex Bereza <alex@bereza.email> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com> Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-10selftests/ftrace: Fix unique symbol check in kprobe_non_uniq_symbol.tcgraftedSven Schnelle
The current regex also matches symbols in modules, which makes the test fail on s390 where name_show is present only once in the kernel, but also multiple times in modules: 000001b1401cdc20 t name_show 000001b0c05e6c40 t name_show [mdev] 000001b0c0495f30 t name_show [i2c_core] Fix this by changing the regular expression to only match the function name. Link: https://lore.kernel.org/all/20260909092954.2200558-1-svens@linux.ibm.com/ Fixes: 03b80ff8023a ("selftests/ftrace: Add new test case which checks non unique symbol") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-09-09nitro_enclaves: fix use-after-free on SLOT_ALLOC failureYuxiao Wang
When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave. In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release. The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object. Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet. Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected. Fixes: 9c8eb50fe9e2 ("nitro_enclaves: Add logic for terminating an enclave") Cc: stable@vger.kernel.org Co-developed-by: Zhaofeng Chen <zhaofeng.chen@certik.com> Signed-off-by: Zhaofeng Chen <zhaofeng.chen@certik.com> Signed-off-by: Yuxiao Wang <yuxiao.wang@certik.com> Reviewed-by: Alexander Graf <graf@amazon.com> Link: https://patch.msgid.link/20260909124400.27857-1-graf@amazon.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-09-09dmaengine: wait for RCU readers before releasing dma_deviceShivank Garg
dma_issue_pending_all() walks the dma_device_list with list_for_each_entry_rcu() under rcu_read_lock(). dma_device_release() unlinks the device with list_del_rcu() and then calls device->device_release() (which in many drivers, such as plx_dma.c, directly calls kfree()). Because there is no grace period between unlinking the device and freeing it, concurrent RCU readers in dma_issue_pending_all() can access the device after it has been freed. The lockless walk originally relied on clients holding a dmaengine reference to pin the provider module, and therefore the device, for as long as they might traverse the list. Commit 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") decoupled the dma_device lifetime from the module reference, so the device can now be released while a reader is still walking the list. Add synchronize_rcu() before the device is freed, so RCU readers are guaranteed to have finished. Keep it unconditional: providers that do not implement device_release() free the device themselves once dma_async_device_unregister() returns. This call will delay for a grace period with dma_list_mutex held, which is safe and only teardown path is delayed. Fixes: 2ba05622b8b1 ("dmaengine: provide a common 'issue_pending_all' implementation") Suggested-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260526-dmaengine-kref-fix-v2-0-3df60afac01d@amd.com Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Shivank Garg <shivankg@amd.com> Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-4-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-09dmaengine: fix use-after-free in dma_chan_put() and dma_release_channel()graftedShivank Garg
When dma_device_put() drops the last reference on chan->device->ref, dma_device_release() runs and may free the dma_device along with its channels. dma_chan_put() then still reads chan->device->owner via dma_chan_to_owner() for the trailing module_put(). KASAN catches it: slab-use-after-free in dma_chan_put+0x3e6/0x4c0 Read of size 8 by task insmod/6319 Freed by task 6319: kfree+0x225/0x470 dma_chan_put+0x395/0x4c0 dmaengine_put+0xf8/0x160 Cache the module owner in dma_chan_put() before the put so the trailing module_put() does not need chan->device. Fixes: 8ad342a86359 ("dmaengine: Add reference counting to dma_device struct") Suggested-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260518-dmaengine-kref-fix-v1-1-4d6125048fb7@amd.com Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Shivank Garg <shivankg@amd.com> Link: https://patch.msgid.link/20260822-dmaengine-kref-fix-v5-3-d4a4ee47d927@amd.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-08soundwire: cadence_master: wait and cancel cdns->work before clock stopBard Liao
A peripheral event could happen during the clock stop process. We need to wait for the event be handled before stopping the bus clock. Otherwise, we will get the IO transfer timed out issue. Fixes: af4cc917826f ("soundwire: cadence: mask Slave interrupt before stopping clock") Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: David Lin <david.lin@intel.com> Reviewed-by: Shuming Fan <shumingf@realtek.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260901031019.233254-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-09-07iio: proximity: vcnl3020: fix ISR bitmask check in IRQ handlerSalah Triki
The threaded IRQ handler contained multiple issues in handling interrupt events and clearing status flags: 1. ISR bit check: The handler incorrectly checked the Interrupt Status Register (VCNL_ISR) against VCNL_ICR_THRES_EN (BIT(1)), which is a bitmask meant for the Control Register (VCNL_PS_ICR). In VCNL_ISR, BIT(1) corresponds only to low-threshold interrupts. A high-threshold interrupt (VCNL_INT_TH_HI, BIT(0)) on its own was completely ignored and returned IRQ_NONE. 2. Event direction & channel index: The handler unconditionally pushed a RISING event code on channel index 1. The driver only registers a single proximity channel (index 0), and low-threshold interrupts should be reported with IIO_EV_DIR_FALLING. 3. ISR clearing: The write-back to acknowledge the interrupt only preserved BIT(1) instead of masking against both valid status bits. Fix this by checking both VCNL_INT_TH_HI and VCNL_INT_TH_LOW bits in VCNL_ISR, pushing separate IIO events with the correct direction and channel index (0), and properly clearing handled status bits. Fixes: 3363fbbe19e5 ("iio: proximity: vcnl3020: add periodic mode") Signed-off-by: Salah Triki <salah.triki@gmail.com> Reviewed-by: Ivan Mikhaylov <fr0st61te@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-09-07iio: proximity: vl53l0x-i2c: claim direct mode for raw readsgraftedDonggeun Yoo
vl53l0x_read_raw() starts a single-shot ranging measurement and reads back the result. Once the triggered buffer is enabled the sensor runs in continuous mode and its data-ready interrupt is routed to the trigger, so a concurrent in_distance_raw read disturbs the streaming setup and never gets its completion, returning -ETIMEDOUT. The original submission claimed direct mode here, but it was dropped during review because the driver had no buffer support at the time [1]. Continuous (buffered) mode was later added without restoring the claim [2], reintroducing the conflict. Reject direct reads while buffered capture is active by claiming direct mode around the measurement, as the vl53l1x sibling already does. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Link: https://lore.kernel.org/linux-iio/20180911160300.GA9212@himanshu-Vostro-3559/ [1] Link: https://lore.kernel.org/linux-iio/20240909101508.263085-3-abhashkumarjha123@gmail.com/ [2] Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-09-06Linux 7.3-rc2v7.3-rc2Linus Torvalds
2026-09-06Merge tag 'trace-v7.3-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull tracing fixes from Steven Rostedt: - Fix several tracefs files that did not take the trace_array reference A trace instance can be created and destroyed in the tracefs "instances" directory via mkdir and rmdir respectively. The instance is represented by a trace_array descriptor. Most tracefs files pass the trace_array as the private data of the inode to the open/read/write functions. Since there is no locking between the time a task opens a file and the deletion of the instance (and the freeing of the trace_array), each open needs to get a reference to the trace_array and each close must remove it. An instance can't be removed if there's any reference taken on its trace_array. The open function uses trace_array_get() that takes a lock (preventing removal of instances) and iterates the list of all existing trace_arrays and if it finds a match, it takes the reference and releases the lock. If it doesn't find a match, it causes the open to return -ENODEV. There were some added files that did not take the trace_array reference on open that needed to be fixed. Sashiko also correctly pointed out that there were some files that took an address of an field or element of the trace_array which had a pointer back to the trace_array to take its reference on open. But this leaves a slight race between referencing this element to get the trace_array as the element itself could be freed. To solve this, some helper functions were created to look for trace_arrays with this field or element in the search so that the element did not have to be dereferenced before the trace_array's reference was taken. - Add a lock around ftrace_ops initialization When a ftrace_ops is first used by ftrace, some internal initialization is performed on the ops. But if multiple tasks were calling functions that did this initialization, it could race and perform doing the initialization more than once, corrupting the internal data. Add a lock in the initialization code to prevent this from happening. - Fix splice reads on mmapped buffers The logic in the ring buffer splice code for mmapped buffers is supposed to do a copy of the memory as the mapped buffers can't be given to splice. But there was an if statement within the copy code that would return a -1 if a request for a full page was done and it wasn't a partial read. This is because this logic was written before mmapped buffers existed and this case didn't make sense at the time. For mmapped buffers it makes perfect sense and by returning early can drop a lot of pages unnecessarily. - Have the persistent ring buffer validation check nr_subbufs Sashiko reported that the validation code was relying on the saved nr_subbufs to match the calculated nr_pages + 1 and if they were off, that the code could cause corruption. Sashiko is correct, and the saved nr_subbufs should be validated before assuming it is correct. - Do not allow more than one instance with the same name on cmdline If an admin were to add more than one trace instances with the same name they all would be created, but only the first one would be accessible via tracefs. This used to not be allowed but some restructuring of code has since made it possible. - Fix the race between subbuf resize and trace_pipe_raw readers If a task was reading trace_pipe_raw while another task was changing the ring buffer subbuf size, it could crash the reader. The trace_pipe_raw readers do get their own copy of the page from the buffer, but the code needs some restructuring to not have the resize of the subbuffers cause issues. - Cap the size of the mapped (static) ring buffer nr_pages The meta data used for ring buffer mapped buffers is 32 bit in size. A normal ring buffer could (in theory) have more than 4 billion pages. But this is not allowed by mapped buffers, so enforce it. * tag 'trace-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: ring-buffer: Use a macro for static buffer bits tracing: Fix comment in tracing_buffers_splice_read() ring-buffer: Prevent truncation of nr_pages / nr_subbufs ring-buffer: Cap static ring buffer nr_pages tracing: Fix subbuf resize races with trace_pipe_raw readers tracing: Fix to avoid creating trace instances with duplicate names ring-buffer: Add checking nr_subbufs to persistent ring buffer validation ring-buffer: Allow splice reads on static buffers tracing: Take trace_array reference when opening options file ftrace: Synchronize the initialization of ftrace_ops ftrace: Take trace_array reference before accessing its ftrace_ops tracing: Have show_event_filters/triggers files take trace array ref
2026-09-06Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfLinus Torvalds
Pull bpf fixes from Alexei Starovoitov: "This mainly contains verifier fixes that address bugs reported by Nicholas Carlini. - Fix incorrect non-NULL inference in pointer comparisons: pointer types that may be NULL at runtime, pointers with unbounded offsets, JMP32 comparisons with zero, and imprecise zero registers (Eduard Zingerman) - Fix precision tracking for half-dead zero spills, ld_abs/ld_ind implicit subprog exit, bpf_loop() callbacks, linked scalar ids and NULL call arguments (Eduard Zingerman) - Reject BPF_PSEUDO_FUNC reference to the main program, fix zero extension of arena 32-bit cmpxchg, don't rewrite bpf_fastcall patterns entered by a jump (Eduard Zingerman) - Fix percpu map update and BPF_F_CPU validation with sparse CPU IDs (Hui Su) - Fix NULL-ptr-derefs in bpf_snprintf_btf() for void and VAR types, and reject key-less BTF for hash maps (Jiayuan Chen) - Various fixes (Kumar Kartikeya Dwivedi): - Fix out-of-bounds access in disassembler on invalid LDSX instruction - mark siginfo of signal tracepoints as scalar and sched_process_wait argument as nullable - mark faultable stack helpers as sleepable - reject tail calls and legacy packet loads from callbacks - enforce rbtree callback lock restrictions for resilient locks - require MEM_PERCPU for percpu kptr stores - clear NON_OWN_REF after RCU protection ends - mark NULL kptr stores precise - preserve inner map identity in callback frames - reject non-scalar bpf_loop() iteration counts - Fix trampoline allocation slowdown on x86 by using EXECMEM_MODULE_DATA (Mike Rapoport) - Keep bpf_refcount_acquire() nullable for borrowed RCU kptrs and reject untrusted allocated-object pointers (Ning Ding) - Fix special fields handling in recycled rhtab elements (Nuoqi Gui, Yuan Chen)" * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: (86 commits) bpf, riscv: Make arena support depend on ZACAS selftests/bpf: Test pointer bpf_loop iteration count rejection bpf: Reject non-scalar bpf_loop iteration counts bpf: use mark_arg_precision() in check_mem_size_reg() bpf: propagate mark_chain_precision() errors out of loop_flag_is_zero() selftests/bpf: precision of a NULL global subprogram BTF_ID argument bpf: mark a NULL BTF_ID argument of a global subprogram precise selftests/bpf: precision of a NULL kfunc argument bpf: mark a NULL kfunc argument precise selftests/bpf: precision of a NULL global subprogram memory argument bpf: mark a NULL memory argument of a call precise selftests/bpf: precision of a NULL helper argument bpf: mark a NULL call argument precise selftests/bpf: Test inner map identities in callbacks bpf: Preserve inner map identity in callback frames selftests/bpf: Test imprecise scalar kptr stores bpf: Mark NULL kptr stores precise selftests/bpf: Test rhtab kptr cancellation semantics bpf: Cancel special fields when recycling rhtab elements selftests/bpf: Test timer field on recycled rhtab element ...
2026-09-06Merge tag 'sched-urgent-2026-09-06' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: - Fix a timestamping bug in pick_task_fair() and yield_task_fair() (Zhan Xusheng) - Skip migrate-disabled tasks when picking a push candidate in the RT and DL schedulers (Seiji Nishikawa) - Skip rq->avg_idle update without a valid idle_stamp (Shubhang Kaushik) - Fix throttling bug in throttle_cfs_rq(), caused by the recent single-runqueue conversion (Wanwu Li) - Fix bandwidth calculation bug in distribute_cfs_runtime(), caused by the single-runqueue conversion (Wanwu Li) - Don't make x86 ITMT enablement depend on debugfs (Mario Limonciello) - Avoid creating misfits during cache-aware load-balancing on hybrid systems (Tim Chen) * tag 'sched-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/fair: Avoid creating misfits during cache-aware balancing x86/itmt: Don't make ITMT enablement depend on debugfs sched/fair: Use cfs_rq->h_curr in distribute_cfs_runtime() sched/fair: Use cfs_rq->h_curr in throttle_cfs_rq() sched/core: Skip rq->avg_idle update without a valid idle_stamp sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate sched/fair: Use update_curr_eevdf() for the remaining root cfs_rq callers
2026-09-06Merge tag 'perf-urgent-2026-09-06' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf events fixes from Ingo Molnar: - Skip empty AUX records with only format flags (Leo Yan) - Fix use-after-free when perf mmap() revival races with the last munmap() (Yilin Zhang, Weiming Shi) * tag 'perf-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix use-after-free when perf mmap() revival races with the last munmap() perf/core: Skip empty AUX records with only format flags
2026-09-06Merge tag 'locking-urgent-2026-09-06' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Ingo Molnar: - Fix a softirq processing delay bug in local_interrupt_disable(), which should mostly only affect the Rust runtime (Boqun Feng) - Remove the hardirq_disable_count() function which caused the previous bug and is now unused & unnecessary (Boqun Feng) - lockdep: Invalidate stale class_cache entries for zapped classes (Eric Dumazet) - Fix rt_mutex specific futex scheduling helpers (Sebastian Andrzej Siewior) - Fix rcuwait use-after-free race during futex requeue PI (Yao Kai) * tag 'locking-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: futex: Prevent rcuwait use-after-free during requeue PI futex: Provide rt_mutex_.*_schedule() equivalents for futex scheduling locking/lockdep: Invalidate stale class_cache entries for zapped classes preempt: Remove hardirq_disable_count() interrupt: Disable interrupt before modifying hardirq_disable counter
2026-09-06Merge tag 'irq-urgent-2026-09-06' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull IRQ subsystem fixes from Ingo Molnar: - Revert a commit to the mbigen irqchip driver that caused a regression on two-port Hi1616 chips (Caina) - Fix a too-long-preemption-off bug in the stm32mp-exti irqchip driver, caused by a time unit ambiguity & mismatch (Ju Nan) - Remove the now completely unused irq_domain_add_linear() inline function (Jiri Slaby) * tag 'irq-urgent-2026-09-06' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/stm32mp-exti: Fix the unit of the hwspinlock timeout Revert "irqchip/mbigen: Fix mbigen node address layout" irqdomain: Delete irq_domain_add_linear()
2026-09-06Merge tag 'tty-7.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull virtio console fix from Greg KH: "Here is a single virtio console fix for 7.3-rc2 to fix a much reported regression in 7.3-rc1, sorry about that. It's not been in linux-next, but it has been sent by many different developers to resolve the issue and is 'obviously' correct" * tag 'tty-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: virtio_console: allocate the port_buffer with the caller's gfp
2026-09-06Merge tag 'staging-7.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver fixes from Greg KH: "Here are some small staging driver fixes to resolve some reported bugs that have been found, and tested, in a few staging drivers in 7.3-rc1. Included in here are: - OOB read problem fixes in the rtl8723bs driver - fbtft driver fix - sm750fb driver fix All of these have been in linux-next this week with no reported problems" * tag 'staging-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: sm750fb: fix mono image source stride mismatch in lynxfb_ops_imageblit() staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie() staging: rtl8723bs: fix OOB read in rtw_action_frame_parse() staging: rtl8723bs: fix OOB read / stack overflow in rtw_get_wps_attr() staging: fbtft: make dirty_lock IRQ-safe
2026-09-06Merge tag 'usb-7.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB fixes from Greg KH: "Here are some small USB driver fixes for reported problems and regressions. Include in here are: - xhci driver fixes - cdns3 driver fixes - usb gadget driver fixes for syzbot found problems - typec driver fixes for broken hardware and other bugs found - kernel data leaks in mdc800 driver - usb storage driver fixes - other small USB driver fixes All of these have been in linux-next this week with no reported issues" * tag 'usb-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (25 commits) usb: typec: qcom-pmic-typec: drain cc_debounce_dwork if port_start() fails usb: typec: qcom-pmic-typec: disable cc_debounce_dwork on stop usb: gadget: fix null pointer dereference in usb_put_function_instance() usb: typec: qcom-pmic: cancel reset_work on stop usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers() usb: f_mass_storage: Bump local buffer size in fsg_common_create_luns() usb: storage: realtek_cr: fix use-after-free on disconnect usb: cdnsp: fix wakeup from S3 after controller context loss usb-storage: ene_ub6250: fix race between scan work and probe USB: gadget: fix NULL pointer dereference in gadget_dev_ioctl() usb: gadget: f_midi: initialize work in f_midi_alloc() usb: gadget: f_midi2: fix use-after-free in string attribute show path usb: typec: tipd: Fix Thunderbolt altmode VDOs for cd321x usb: gadget: midi2: Fix null-pointer dereference in f_midi2_free_ep_reqs usb: typec: hd3ss3220: track VBUS enable state per consumer usb: dwc3: clear forceRM when issuing EndTransfer usb: dwc3: google: Initialise probe properties with DWC3_DEFAULT_PROPERTIES usb: typec: mux: avoid duplicated mux switches usb: typec: mux: Fix typec_switch_match() usb: image: mdc800: change kmalloc() to kzalloc() ...
2026-09-06bpf, riscv: Make arena support depend on ZACASChen Pei
The arena range tree allocates its nodes with kmalloc_nolock() since commit f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree"). kmalloc_nolock() requires slab caches with cmpxchg128 support (__CMPXCHG_DOUBLE); on riscv cmpxchg128 is provided by the ZACAS extension. On systems without ZACAS every arena map creation fails with a misleading -ENOMEM. Report the missing support instead: make bpf_jit_supports_arena() return system_has_cmpxchg128() where it is defined, so arena map creation fails with -EOPNOTSUPP on systems without ZACAS. The macro is only defined when both CONFIG_RISCV_ISA_ZACAS and CONFIG_TOOLCHAIN_HAS_ZACAS are enabled, so guard it with #ifdef the same way mm/slab.h consumes it, and reject arena otherwise. This matches how arena BPF_CMPXCHG instructions are already gated on ZACAS in bpf_jit_supports_insn(). Fixes: f8c67d8550ee ("bpf: Use kmalloc_nolock() in range tree") Signed-off-by: Chen Pei <cp0613@linux.alibaba.com> Acked-by: Pu Lehui <pulehui@huawei.com> Acked-by: Björn Töpel <bjorn@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/bpf/20260902061451.1416-1-cp0613@linux.alibaba.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-09-05Merge branch 'fix-bpf_loop-syzbot-report'Eduard Zingerman
Kumar Kartikeya Dwivedi says: ==================== Fix bpf_loop syzbot report Needs Eduard's ack. Fix for the report in https://lore.kernel.org/bpf/6a9ad24c.b5d4176b.238c3e.0001.GAE@google.com. ==================== Link: https://patch.msgid.link/20260905014735.1452988-1-memxor@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-09-05selftests/bpf: Test pointer bpf_loop iteration count rejectionKumar Kartikeya Dwivedi
Add a verifier test that leaves the raw tracepoint context pointer in R1 when calling bpf_loop(). This is the smallest trigger for the incorrect precision backtracking: it reuses an existing callback and needs no maps or userspace setup. Expect an ordinary scalar-type rejection. Without the verifier fix, the test instead reaches precision backtracking and reports an internal "backtracking misuse" error. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://patch.msgid.link/20260905014735.1452988-3-memxor@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-09-05bpf: Reject non-scalar bpf_loop iteration countsKumar Kartikeya Dwivedi
bpf_loop() declares its nr_loops argument as ARG_ANYTHING. Privileged programs may pass pointer values to such arguments, so check_func_arg() lets a pointer-valued R1 reach the helper-specific checks. Since commit bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations"), the verifier marks R1 precise and reads its upper bound to limit callback simulation. Precision backtracking only accepts scalar registers, so passing a pointer instead triggers the "backtracking misuse" verifier warning. Kernels with panic_on_warn enabled subsequently panic. Introduce ARG_SCALAR for helper arguments that only accept scalar values and use it for bpf_loop() nr_loops. Generic helper argument validation then rejects pointers before loop inlining and precision processing. Fixes: bb124da69c47 ("bpf: keep track of max number of bpf_loop callback iterations") Reported-by: syzbot+7b47f87674e9a1569110@syzkaller.appspotmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://patch.msgid.link/20260905014735.1452988-2-memxor@gmail.com Closes: https://lore.kernel.org/bpf/6a9ad24c.b5d4176b.238c3e.0001.GAE@google.com/ Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-09-05Merge tag 'kmalloc_obj-v7.3-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull kmalloc_obj conversions from Kees Cook: "Another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci" * tag 'kmalloc_obj-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: treewide: refresh kmalloc_obj() conversions drm/amd/display: Fix harmless type mismatch in allocation
2026-09-05Merge tag 'driver-core-7.3-rc2' of ↵graftedLinus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Fix kernfs listxattr() not returning security xattr names (e.g. SELinux labels) when the kernfs node has no allocated kernfs_iattrs - Fix silent truncation of IRQ vector indices in the Rust PCI abstractions - Don't select OF from DRIVER_PE_KUNIT_TEST; skip the test when OF is disabled instead of silently enabling extra kernel functionality - Russ Weight is retiring from kernel development; update the Firmware Loader sysfs contact to the driver-core mailing list, add a CREDITS entry for Firmware Upload, and update MAINTAINERS accordingly * tag 'driver-core-7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: MAINTAINERS: Remove Russ Weight from Firmware Loader CREDITS: Add CREDITS entry for Firmware Upload firmware_loader: Change contact for sysfs nodes rust: pci: reject IRQ vector indices that do not fit in u32 kernfs: preserve security xattrs without allocating iattrs drivers: base: test: DRIVER_PE_KUNIT_TEST should not select OF
2026-09-05virtio_console: allocate the port_buffer with the caller's gfpBreno Leitao
put_chars() runs from the hvc console write path with preemption disabled, so it asks alloc_buf() for GFP_ATOMIC. Only the data buffer gets it: the struct port_buffer itself keeps the GFP_KERNEL default, so the allocation can enter direct reclaim and sleep. A write to /dev/kmsg on a CONFIG_DEBUG_ATOMIC_SLEEP kernel splats: BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:320 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: virtme-ng-init preempt_count: 1, expected: 0 Preemption disabled at: [<ffffffff813fd90d>] vprintk_emit+0x17d/0x510 Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 __might_resched+0x37a/0x4d0 __kmalloc_cache_noprof+0x94/0x5f0 put_chars+0x209/0x3e0 hvc_console_print+0x234/0x640 console_flush_all+0x4fc/0x950 console_unlock+0xbf/0x1b0 vprintk_emit+0x312/0x510 devkmsg_emit+0xba/0x110 devkmsg_write+0x21b/0x2e0 vfs_write+0x4dc/0x9d0 ksys_write+0x108/0x1e0 do_syscall_64+0xfa/0x460 </TASK> Pass gfp on to that allocation too. Fixes: fc220d6be3c7 ("virtio_console: refactor __send_to_port() buffer ownership") Signed-off-by: Breno Leitao <leitao@debian.org> Acked-by: Sungho Bae <baver.bae@lge.com> Tested-by: Florian Westphal <fw@strlen.de> Link: https://patch.msgid.link/20260810-serial-v1-1-abbe51602c13@debian.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-09-04treewide: refresh kmalloc_obj() conversionsgraftedKees Cook
This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
2026-09-04Merge branch ↵Alexei Starovoitov
'bpf-add-missing-precision-propagation-after-bpf_register_is_null-calls' Eduard Zingerman says: ==================== bpf: add missing precision propagation after bpf_register_is_null calls Fix [1] uncovered a host of locations where the call to bpf_register_is_null() is not followed by a call to bpf_mark_chain_precision(). check_map_kptr_access() is omitted as it is handled [2] by another series. [1] https://lore.kernel.org/bpf/20260904083325.2083493-7-eddyz87@gmail.com/ [2] https://lore.kernel.org/bpf/20260904104203.345917-6-memxor@gmail.com/ --- ==================== Link: https://patch.msgid.link/20260904-register-is-null-precise-fixes-v1-0-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-09-04bpf: use mark_arg_precision() in check_mem_size_reg()Eduard Zingerman
Use newly added mark_arg_precision() helper in check_mem_size_reg(). Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-10-0f5a360ff15d@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>