summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-08net: dsa: microchip: split port_max_mtu() implementationVladimir Oltean
ksz_max_mtu() is a bit cluttered. It would be good for developers and reviewers if they didn't need to look at a common function for hardware they likely don't have, and which is vastly different, when they are interested in only a specific chip. Benefit from the fact that all families listed here have their own dsa_switch_ops, and provide separate implementations for the port_max_mtu() method. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-2-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: split ksz8_change_mtu()Vladimir Oltean
Even among the ksz8 family, there are big differences in the MTU change procedure between KSZ87xx and KSZ88xx (KSZ8463 is like KSZ88xx here). Since we have 3 separate dsa_switch_ops for what constitutes "KSZ8", we can split those procedures into separate functions. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-1-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08Merge branch 'drivers-net-ethernet-replace-__get_free_pages-with-kmalloc'Paolo Abeni
Mike Rapoport says: ==================== drivers/net/ethernet: replace __get_free_pages() with kmalloc() This is a (small) part of larger work of replacing page allocator calls with kmalloc. My initial intention a few month ago was to remove ugly casts [1], but then willy pointed out that Linus objected to something like this [2] and it looks like more than a decade old technical debt. Largely, anything that doesn't need struct page (or a memdesc in the future) should just use kmalloc() or kvmalloc() to allocate memory. kmalloc() guarantees alignment, physical contiguity and working virt_to_phys() and beside nicer API that returns void * on alloc and doesn't require to know the allocation size on free, kmalloc() provides better debugging capabilities than page allocator. Another thing is that touching these allocation sites gives the reviewers opportunity to see if a PAGE_SIZE buffer is actually needed or maybe another size is appropriate. For larger allocations that don't need physically contiguous memory kvmalloc() can be a better option that __get_free_pages() because under memory pressure it's is easier to allocate several order-0 pages than a physically contiguous chunk with the same number of pages. And last, but not least, removing needless calls to page allocator should help with memdesc (aka project folio) conversion. There will be way less places to audit to see if the user was actually using struct page. Also in git: https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-ethernet [1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/ [2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/ ==================== Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-0-58776615db6e@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08sfc: use kmalloc() to allocate logging bufferMike Rapoport (Microsoft)
efx_mcdi_init() allocates a logging buffer for MCDI firmware communication diagnostics. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-4-58776615db6e@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08sfc/siena: use kmalloc() to allocate logging bufferMike Rapoport (Microsoft)
efx_siena_mcdi_init() allocates a logging buffer for MCDI firmware communication diagnostics. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kmalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Edward Cree <ecree.xilinx@gmail.com> Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-3-58776615db6e@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08ice: use kzalloc() to allocate staging buffer for reading from GNSSMike Rapoport (Microsoft)
ice_gnss_read() uses get_zeroed_page() to allocate a staging buffer for reading GNSS module data via I2C bus. This buffer can be allocated with kmalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of get_zeroed_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-2-58776615db6e@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08bnx2x: use kzalloc() to allocate mac filtering listMike Rapoport (Microsoft)
bnx2x_mcast_enqueue_cmd() allocates memory for mac filtering list using __get_free_pages(). This memory can be allocated with kzalloc() as there's nothing special about it to go directly to the page allocator. kmalloc() provides a better API that does not require ugly casts and kfree() does not need to know the size of the freed object. Performance difference between kmalloc() and __get_free_pages() is not measurable as both allocators take an object/page from a per-CPU list for fast path allocations. For the slow path the performance is anyway determined by the amount of reclaim involved rather than by what allocator is used. Replace use of __get_free_page() with kzalloc() and free_page() with kfree(). Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-1-58776615db6e@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08rtla: Also link in ctype.cBastian Blank
rtla started to only link parts of the tools library. It now misses the ctype information used by all the related string operations. Just add another single file to make it build again. Signed-off-by: Bastian Blank <waldi@debian.org> Fixes: 48209d763c22 ("rtla: Add libsubcmd dependency") Link: https://lore.kernel.org/r/ako2S4mzIqWwYuas@steamhammer.waldi.eu.org [ remove duplicated spaces in commit message ] Signed-off-by: Tomas Glozar <tglozar@redhat.com>
2026-07-08lockdep: Enable the printing of held locks of remote running tasks and print ↵Ingo Molnar
task CPU Background: ========== Currently lockdep does not print out the held locks of non-current tasks that are running on some other CPU, due to the fact that the held locks array is in flux and may be unreliable to print. Syzkaller on the other hand found it that the analysis of locking bugs is easier if we print this information too, because the more locking information the merrier. In particular races are bound to have multiple tasks running on different CPUs, and the exclusion of their held locks information is unnecessarily limiting. So while it's still true that printing out their held locks array is racy, it's not as bad as it seems. There's 16 internal callers to lockdep_print_held_locks(): - 14 callers call it with the current task, which should be safe out of box. - 1 caller, debug_show_all_locks(), calls it with RCU held, which should guarantee that 'p' cannot go away under us. - 1 caller, debug_show_held_locks(), exposes the internal API with the constraint that it should only be called by drivers or platform code if the task isn't actively running - we can assume that if it nevertheless does, it will be Their Problem™. As for held locks being changed from under debug_show_held_locks(), while the task cannot go away, so the held-locks array itself is safe (although potentially non-stable), AFAICS the worst-case race can be garbage printed out by print_lock(), not any actual crashes. In particular: unsigned int class_idx = hlock->class_idx; may be stale (belong to a lock that already got released on another CPU), but it should still be a valid class index bound by MAX_LOCKDEP_KEYS, and thus the lock_classes_in_use bitmap use should be safe. The other two accesses are ::acquire_ip and ::instance: printk(KERN_CONT "%px", hlock->instance); print_lock_name(hlock, lock); printk(KERN_CONT ", at: %pS\n", (void *)hlock->acquire_ip); But both are printed out as pointers, so no risk of dereference of a dangling pointer. We may print a garbage pointer. Also note that the check itself doesn't protect debug_show_held_locks() from printing garbage, as there's nothing that keeps a task from becoming runnable a nanosecond after we've run the task_is_running() check. In fact I'd argue that it's better to make this function *more* racy, for the simple robustness reason that we absolutely do not want it to crash even in the racy case. TL;DR: it should be fine to print the held locks of running tasks too, as long as we print out the information as well that a task is running, so that users are aware of any racy output. Implementation: ============== Implement that change. Also re-flow the function and streamline the printout into a single statement for all cases, which changes the 'no locks held by' / '%d lock[s] held by' phrasing that had a dependency on English spelling of plurals, to a uniform: locks held by bash/1234: %d Which spells correctly for 0, 1 and higher values, and should also be easier to parse both for humans and for scripts. Finally, print out the last CPU a task has ran on. This is very useful information for races and for locking bugs in particular. This basically extends the 'on CPU#%d' message we print for running tasks to all tasks we print. Reported-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Suggested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: Boqun Feng <boqun@kernel.org> Cc: Gary Guo <gary@garyguo.net> Cc: Mark Brown <broonie@kernel.org> Cc: Theodore Tso <tytso@mit.edu> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Waiman Long <longman@redhat.com> Link: https://patch.msgid.link/akoeSIQGwqd9cZwd@gmail.com
2026-07-08net: rmnet: annotate endpoint lookup under RTNLRunyu Xiao
rmnet_get_endpoint() is shared by packet receive paths and RTNL-protected control paths. The receive paths already run under RCU/BH context through the RX handler, while the control paths reach rmnet_get_endpoint() after obtaining the rmnet port with rmnet_get_port_rtnl(). The helper walks port->muxed_ep[] with hlist_for_each_entry_rcu(). Pass lockdep_rtnl_is_held() as the non-RCU protection condition so CONFIG_PROVE_RCU_LIST can see the RTNL-protected control-path calls while preserving the existing RCU-reader behavior for data paths. This was found by our static analysis tool and then manually reviewed against the current tree. The dynamic triage evidence is a target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited to documenting the existing protection contract. This is a lockdep annotation cleanup. It does not change endpoint lifetime or hash updates. Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com> Link: https://patch.msgid.link/20260701124017.3205729-1-runyu.xiao@seu.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08drm/i915/guc: Return NULL for missing multi-lrc parentLinmao Li
multi_lrc_create_parent() returns ERR_PTR(0) when there are not enough engines in the class to create a parallel context. ERR_PTR(0) evaluates to NULL, and the only caller already treats NULL as the non-error "not enough engines" case. Return NULL directly to make the non-error path explicit. Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260706071412.559909-1-lilinmao@kylinos.cn
2026-07-08arm64: dts: xilinx: zynqmp-sck: Correct indentationKrzysztof Kozlowski
Correct spaces or mix of tabs+spaces into proper tab-indented lines. No functional impact (same DTB). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-08syscall_user_dispatch: Add kernel.syscall_user_dispatch sysctlGregory Price
Add a matching sysctl to go with CONFIG_SYSCALL_USER_DISPATCH. kernel.syscall_user_dispatch (default 1 - allow) controls whether userspace may arm syscall user dispatch (both via prctl and ptrace). Disarming is always permitted - same semantics as comparable knobs. Disabling while a task has armed syscall user dispatch does not cause it to become inactive - instead it remains active until the user attempts to disable/re-enable via prctl or ptrace. On the next attempt to re-enable, the prctl/ptrace call fails gracefully. The alternative would cause programs translating non-linux syscalls to interpret those syscalls as linux syscalls, resulting in undefined userland behavior. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260706140020.873735-3-gourry@gourry.net
2026-07-08syscall_user_dispatch: Make it configurable in KconfigGregory Price
Syscall User Dispatch is presently built under CONFIG_GENERIC_SYSCALL and cannot be disabled independently. Add CONFIG_SYSCALL_USER_DISPATCH to make it an optional feature. Signed-off-by: Gregory Price <gourry@gourry.net> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/20260706140020.873735-2-gourry@gourry.net
2026-07-08gtp: annotate PDP lookups under RTNLRunyu Xiao
The GTP PDP lookup helpers are shared by RCU-protected data and report paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The helpers walk RCU hlists, but they do not currently pass the RTNL condition for the control-path lookups. Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing RCU-reader callers remain valid because the RCU-list macros also accept an active RCU read-side section; the added condition only documents the non-RCU protection already used by RTNL control paths. This was found by our static analysis tool and then manually reviewed against the current tree. The dynamic triage evidence is a target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited to documenting the existing protection contract. This is a lockdep annotation cleanup. It does not change PDP lifetime or hash updates. Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260701123925.3193089-1-runyu.xiao@seu.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08tools/resolve_btfids: Include libsubcmd headers directly from source treeThomas Weißschuh
Currently each build with resolve_btfids enabled unnecessarily prints the line 'INSTALL libsubcmd_headers' from libsubcmd. Use the libcmd headers from source tree instead, without installation. The same was done for objtool in commit ac999926774a ("objtool: Include libsubcmd headers directly from source tree"), albeit for a different reason. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://patch.msgid.link/20260702-libsubcmd-spam-v1-1-300ec142a62f@linutronix.de Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-08net: mdio: select REGMAP_MMIO instead of depending on itRosen Penev
REGMAP_MMIO is a hidden (non-user-visible) tristate symbol. Using depends on it is incorrect because there is no way for the user to enable it directly. Change to select, which is the convention used by every other driver in the tree that needs REGMAP_MMIO. Fixes: 8057cbb8335c ("net: mdio: mscc-miim: Add depend of REGMAP_MMIO on MDIO_MSCC_MIIM") Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260702032653.1580616-1-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08selftests/net/openvswitch: add output truncation testMinxi Hou
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test verifies truncation limits in four steps: reject trunc(1) and trunc(13) which are below ETH_HLEN, confirm normal forwarding works, apply trunc(14) which truncates packets to the Ethernet header and verify ping fails, then restore normal forwarding and verify recovery. The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output time; the receiver drops the runt frame and no echo reply is generated. Signed-off-by: Minxi Hou <houminxi@gmail.com> Reviewed-by: Aaron Conole <aconole@redhat.com> Link: https://patch.msgid.link/20260702074926.1174810-1-houminxi@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08selftests: gpio: add gpio-cdev-uaf to .gitignoreCihan Karadag
Commit c7f92042d3f3 ("selftests: gpio: Add gpio-cdev-uaf tests") added the gpio-cdev-uaf binary to TEST_GEN_PROGS_EXTENDED but never added it to .gitignore. Building it with: make -C tools/testing/selftests/gpio TARGETS=gpio leaves gpio-cdev-uaf as an untracked file. Fixes: c7f92042d3f3 ("selftests: gpio: Add gpio-cdev-uaf tests") Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org> Link: https://patch.msgid.link/20260707235707.1349969-1-cihan.cihan@gmail.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-08Merge branch 'fix-for-untrusted-btf-pointer-writes'Eduard Zingerman
Kumar Kartikeya Dwivedi says: ==================== Fix for untrusted BTF pointer writes When using custom btf_struct_access() callbacks, we miss rejecting unstrusted BTF pointer writes. Fix and add a selftest for coverage. Changelog: ---------- v1 -> v2 v1: https://lore.kernel.org/bpf/20260707190214.1997705-1-memxor@gmail.com * Add missing fixes tag. * Add Amery's acks. ==================== Link: https://patch.msgid.link/20260708030752.2503467-1-memxor@gmail.com Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-08selftests/bpf: Add untrusted BTF write regressionKumar Kartikeya Dwivedi
Add a TCP congestion-control struct_ops load test for a write through a BTF pointer produced by bpf_rdonly_cast(). The test expects the verifier to reject the program before the TCP CA btf_struct_access callback can whitelist the tcp_sock field write. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-08bpf: Reject writes through untrusted BTF pointersNicholas Dudar
check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases. Fixes: 282de143ead9 ("bpf: Introduce allocated objects support") Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
2026-07-08riscv: hwprobe.rst: Document EXT_ZICFISS and EXT_ZICFILPGuodong Xu
RISCV_HWPROBE_EXT_ZICFISS and RISCV_HWPROBE_EXT_ZICFILP are defined in the hwprobe uAPI but are not documented in Documentation/arch/riscv/hwprobe.rst. Add documentation for them. Link: https://github.com/riscv/riscv-cfi/commit/302a2d45c2435940d9a63571c66bc038adc74133 Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-3-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08riscv: hwprobe.rst: Make indentation consistentAndrew Jones
A handful of vendor-extension entries indent continuation lines with a tab character, while the rest of hwprobe.rst uses spaces. In addition, many list items align their continuation lines under the 'm' of ':c:macro:' (column 7) rather than under the item text (column 4), so the file mixes several indentation styles. Replace the tabs with spaces and align every list item's continuation lines under the item text, giving the whole file one consistent style. Whitespace-only change, no functional change. [Guodong: extend from tabs->spaces to normalizing all continuation-line indentation across the file] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-2-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08dt-bindings: riscv: sort multi-letter Z extensions alphanumericallyGuodong Xu
The multi-letter extension enum is documented as being sorted alphanumerically (see the "multi-letter extensions, sorted alphanumerically" comment), but several Z entries have drifted out of order. Reorder the affected entries so the multi-letter Z list is sorted alphanumerically again. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-1-2c61f94a695a@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-07-08erofs: get rid of erofs_is_ishare_inode() helperGao Xiang
Just open-code it for simplicity since FS_ONDEMAND no longer exists. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2026-07-08erofs: relax sanity check for tail pclusters due to ztailpackingGao Xiang
If the tail data can be inlined into the inode meta block, it should be converted into a regular tail pcluster. In principle, it should be converted into an uncompressed pcluster if there is not enough gain to use compression (map->m_llen < map->m_plen); but since there are various shipped images, relax the condition for ztailpacking tail pcluster fallback instead of reporting corruption incorrectly. Reported-and-tested-by: Yifan Zhao <zhaoyifan28@huawei.com> Reported-by: Alberto Salvia Novella <es20490446e@gmail.com> Closes: https://github.com/erofs/erofs-utils/issues/51 Fixes: a5242d37c83a ("erofs: error out obviously illegal extents in advance") Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2026-07-07perf data convert json: Fix trace_seq memory leak in process_sample_event()Tanushree Shah
Unlike the in-kernel trace_seq which uses a statically allocated buffer, the userspace traceevent library's trace_seq uses a dynamically allocated one. Therefore, every trace_seq_init() call must be paired with a trace_seq_destroy(), otherwise it produces a memory leak. In process_sample_event(), a trace_seq is initialized for each field when formatting tracepoint raw_data, but the matching trace_seq_destroy() is never called, leaking memory for every field of every sample processed. Add the missing trace_seq_destroy() after using the trace_seq buffer to properly free the allocated memory. Detected with Valgrind on a perf.data file with 2,729 tracepoint samples: Before: definitely lost: 55,537,664 bytes in 13,559 blocks After: definitely lost: 0 bytes in 0 blocks Fixes: 9d895e468429 ("perf data: Add tracepoint fields when converting to JSON") Signed-off-by: Tanushree Shah <tshah@linux.ibm.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-07-07perf record: fix poll storm when monitored threads exitJiawei Sun
When `perf record` samples a multi-threaded process and one of the target threads exits during the session, perf itself may start burning 100% CPU (up to 200% across two cores) until the session ends. A single dead fd is sufficient to trigger this; it can be reproduced with 15 pthreads in a compute loop where one thread exits halfway through. The root cause is two independent instances of the same defect: dead perf_event ring-buffer fds are left in a pollfd array. When a monitored thread exits, the kernel closes its ring-buffer fd, which then returns POLLHUP. POSIX specifies that poll() always reports POLLHUP and POLLERR regardless of the events mask, so any dead fd left in the array makes poll() return immediately every time, spinning in a tight loop: 3 seconds: 256,600 poll() calls, 0 context switches, only 21 write() Woken up count goes from ~0 to 1,300,000+ There are two affected poll paths, fixed together here: 1. Record main loop, via fdarray__filter() (tools/lib/api/fd/array.c). Since commit 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") it only zeroes events/revents without setting fd to -1, so poll() keeps reporting POLLHUP for the entry. Setting fd = -1 makes poll() skip it, matching the pattern already used in the control-fd path at tools/perf/builtin-record.c:1673. 2. BPF sideband thread, perf_evlist__poll_thread() (tools/perf/util/sideband_evlist.c). This thread polls for PERF_RECORD_BPF_EVENT but, unlike the main record loop, never calls fdarray__filter() at all, so dead fds accumulate forever and it spins at 100% CPU: Before fix: dJiffies=101, wchan=0 (running) After fix: dJiffies=0, wchan=do_sys_poll (blocking) Fixed by calling the existing evlist__filter_pollfd() helper after evlist__poll(), mirroring the main record loop. <poll.h> is included for the POLLERR/POLLHUP macros (previously unused there). The two fixes compose: fix 1 makes poll() ignore dead fds (fd=-1); fix 2 ensures the sideband thread actually performs the filtering. Both paths are affected in all kernels from v5.1/v5.9 to the current master (7.2-rc1); the source of both functions is byte-identical across them. BPF event recording is preserved: after the fix, perf.data still contains PERF_RECORD_BPF_EVENT records and bpf_prog_info entries. Verified on perf 6.1.76, 6.6.143 and 7.2-rc1 with a minimal reproducer (Woken up 1,300,000 -> 3, CPU 100% -> 0%) and an A/B orthogonal test: keeping the unpatched binary but preventing the target thread from exiting also makes the storm disappear, confirming the trigger. Fixes: 59b4412f27f1 ("libperf: Avoid internal moving of fdarray fds") Fixes: 657ee5531903 ("perf evlist: Introduce side band thread") Signed-off-by: Jiawei Sun <abyssmystery@gmail.com> Reviewed-by: Ian Rogers <irogers@google.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org>
2026-07-08staging: rtl8723bs: drop GEN_EVT_CODE macro and capitalize labelsAiman Najjar
The use of GEN_EVT_CODE macro to generate event enum label names is applied inconsistently and is confusing, it also makes it harder to make use of tools such as clangd when looking up symbols. Replace them with writing the enum labels directly and adopting new capitalized names instead of the current camel case ones. Signed-off-by: Aiman Najjar <aiman.najjar@hurranet.com> Link: https://patch.msgid.link/20260707-rtl8723bs-code-style-v2-2-df50f0eead17@hurranet.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08staging: rtl8723bs: drop GEN_CMD_CODE macro and capitalize labelsAiman Najjar
The use of GEN_CMD_CODE macro to generate cmd enum label names is applied inconsistently and is confusing, it also makes it harder to make use of tools such as clangd when looking up symbols. Replace them with writing the enum labels directly and adopting new capitalized names instead of the current camel case ones. Also clean up unused alias macros in rtw_cmd.h Signed-off-by: Aiman Najjar <aiman.najjar@hurranet.com> Link: https://patch.msgid.link/20260707-rtl8723bs-code-style-v2-1-df50f0eead17@hurranet.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08staging: axis-fifo: Align arguments to open parenthesisHari Mishal
Align the second argument of wait_event_interruptible() with the open parenthesis to fix a checkpatch warning. Signed-off-by: Hari Mishal <harimishal1@gmail.com> Link: https://patch.msgid.link/20260707182038.37405-1-harimishal1@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-07-08ata: libata-core: Allow capacity transition to zero for locked drivesTJ Adams
Commit 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security locked drive") introduced setting the device capacity (n_sectors) to zero in ata_dev_configure() if the drive is security locked. However, during runtime revalidation, ata_dev_revalidate() compares the new capacity (now 0) with the old capacity (>0) and detects a mismatch. Since it does not consider the locked status, it returns -ENODEV. This revalidation failure can occur when doing a reset of the PHY (e.g. hard reset) for a controller that has I/Os in flight. The timed out I/Os trigger the SCSI Error Handling (EH) path, which in turn invokes libata device revalidation. If the drive is locked at runtime (e.g. it lost power during reset and relocked), revalidation sees the capacity transition to zero and fails, eventually disabling the device. Fix this by allowing the capacity transition to zero in ata_dev_revalidate() if the drive is reported as security locked by ata_id_is_locked(). Fixes: 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security locked drive") Cc: stable@vger.kernel.org Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Terrence Adams <tadamsjr@google.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-07-08ata: libata-core: Skip HPA resize for locked drivesTJ Adams
Skip HPA resize in ata_hpa_resize() if the drive is security locked. If the drive is locked, the command to read the native max address fails with -EACCES, which currently causes the sticky quirk ATA_QUIRK_BROKEN_HPA to be set on the device. Setting this sticky quirk causes subsequent revalidations (after the drive is unlocked) to bypass HPA checks, preventing the unlocked drive from exposing its full native capacity without a reboot or device removal. Cc: stable@vger.kernel.org Signed-off-by: Terrence Adams <tadamsjr@google.com> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-07-07accel/amdxdna: Fix potential NULL pointer dereference of abo->clientLizhi Hou
Closing a BO handle clears abo->client, while the underlying GEM object may remain alive due to internal kernel references. As a result, code executed after the BO handle is closed may dereference a NULL abo->client pointer. Remove accesses to abo->client from code paths that may execute after the BO handle has been closed. Fixes: d76856beb4a4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707201556.562191-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Check init_srcu_struct() return valueLizhi Hou
The return value of init_srcu_struct() is currently ignored. If initialization fails, subsequent use of hwctx_srcu may result in invalid memory accesses. Check the return value of init_srcu_struct() and propagate the error to the caller. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707172323.539721-1-lizhi.hou@amd.com
2026-07-07accel/amdxdna: Check drmm_mutex_init() return valueLizhi Hou
drmm_mutex_init() may fail and return an error. Check the return value and abort initialization if mutex creation fails. Fixes: 8c9ff1b181ba ("accel/amdxdna: Add a new driver for AMD AI Engine") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260707172307.539676-1-lizhi.hou@amd.com
2026-07-07clk: qcom: gcc-qcs8300: Use retention for USB power domainsLoic Poulain
The USB subsystem does not expect to lose its state on suspend: xhci-hcd xhci-hcd.1.auto: xHC error in resume, USBSTS 0x401, Reinit usb usb1: root hub lost power or was reset To maintain state during suspend, the relevant GDSCs need to stay in retention mode, like they do on other similar SoCs. Change the mode to PWRSTS_RET_ON to fix. Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-2-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07clk: qcom: gcc-qcs8300: Use retention for PCIe power domainsLoic Poulain
As the PCIe host controller driver does not yet support dealing with the loss of state during suspend, use retention for relevant GDSCs. Fix the PCIe link not surviving upon resume, and GDSC error: gcc_pcie_0_gdsc status stuck at 'off' Fixes: 95eeb2ffce73 ("clk: qcom: Add support for Global Clock Controller on QCS8300") Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629-monza-suspend-v1-1-b601d8a2f2f8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-08selftests/bpf: Rename libarena struct bitmap to struct arena_bitmapYonghong Song
When building bpf selftest with latest bpf-next, I got the following failure: In file included from /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libarena/selftests/test_parallel_bitmap.bpf.c:8: /home/yhs/work/bpf-next/tools/testing/selftests/bpf/libarena/include/libarena/bitmap.h:11:8: error: redefinition of 'bitmap' 11 | struct bitmap { | ^ /home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include/vmlinux.h:51320:8: note: previous definition is here 51320 | struct bitmap { | ^ The vmlinux.h struct bitmap comes from drivers/md/md-bitmap.c: struct bitmap { struct bitmap_counts { ... } ... } To fix the issue, I renamed libarena struct bitmap to arena_bitmap to avoid the conflict. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Link: https://lore.kernel.org/bpf/20260707220136.910374-1-yonghong.song@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-07-07arm64: dts: qcom: talos: Add passive polling-delay for gpu-thermal zoneHaritha S K
Introduce a passive polling delay to ensure more than one "passive" thermal point is considered when throttling the GPU thermal zone. Signed-off-by: Haritha S K <haritha.k@oss.qualcomm.com> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260505-qcs615_gpu_cooling-v2-1-1ba42260b29d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: purwa: Add Microsoft Surface Pro 12inHarrison Vanderbyl
Initial device tree for Microsoft Surface Pro 12in Currently supported: - UFS - Touchscreen - Pen - USB 3.2 x2 (DP Alt Mode) - Audio - Wifi - Bluetooth - CDSP - ADSP - GPU Not currently supported: - Accelerometer - Front, Back and IR cameras - IRIS video decoder Tested on Surface_Pro_12in_1st_Ed_with_Snapdragon_2110 Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260609145906.40854-2-harrison.vanderbyl@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: monaco-arduino-monza: Remove duplicate includesKonrad Dybcio
monaco-arduino-monza.dts includes monaco-monza-som.dtsi, which aleady includes monaco.dtsi and monaco-pmics.dtsi. Remove the duplicates. The resulting DTB file is identical. Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260617-topic-monza_includes-v1-1-fcef9ce489fb@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: sm7325: Add Xiaomi 12 Lite 5G (taoyao) DTSStanislav Zaikin
Xiaomi 12 Lite 5G is a handset released in 2022 This commit has the following features working: - Display (with simple fb) - Touchscreen - UFS - Power and volume buttons - Pinctrl - RPM Regulators - Remoteprocs - wifi, bluetooth - USB (Device Mode) Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260608143329.252033-3-zstaseg@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07dt-bindings: arm: qcom: Add SM7325 Xiaomi 12 Lite 5G (taoyao)Stanislav Zaikin
Xiaomi 12 Lite 5G (xiaomi,taoyao) is a smartphone based on the SM7325 SoC. Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20260608143329.252033-2-zstaseg@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: talos-evk-som: Enable Adreno 612 GPUJie Zhang
Enable GPU for talos-evk-som platform and provide path for zap shader. Signed-off-by: Jie Zhang <jie.zhang@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260427-talos-evt-gpu-v1-1-d40b6dffa108@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: kodiak: avoid EFI overlap for ADSP remote heapJianping Li
On KODIAK platforms boot can fail when the DT "adsp-rpc-remote-heap" reserved-memory region overlaps with firmware allocations (UEFI/EFI runtime). The kernel then reports failure to reserve the region and subsequent EFI runtime activity may trigger aborts. The remote heap node was described as a fixed "no-map" region, which turns it into a hard carveout. Replace it with a "shared-dma-pool" reserved memory region with reusable CMA-backed allocation, specifying alignment and size. This avoids hard carveouts and reduces the chance of conflicting with firmware memory maps while keeping an explicit pool for ADSP remote heap usage. Fixes: 90a58ffa9c55 ("arm64: dts: qcom: kodiak: Add memory region for audiopd") Cc: stable@kernel.org Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260429073443.2027-1-jianping.li@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: sm8750: Add UART15Teguh Sobirin
Add uart15 node for the UART bus present on the sm8750 SoC. Signed-off-by: Teguh Sobirin <teguh@sobir.in> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260605-sm8750-uart15-v1-1-93e660722e61@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: qcs615-ride: fix sdhc_2 vqmmc-supply for UHS-I modeMonish Chunara
SD card is detected as SDHS instead of UHS-I because sdhc_2 was configured with vreg_s4a as vqmmc-supply, which cannot switch between 1.8V and 3.3V. Switch vqmmc-supply to vreg_l2a and update its voltage range to 1800000-2960000 uV to enable proper UHS-I signaling. Signed-off-by: Monish Chunara <monish.chunara@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260522105020.3588377-1-mchunara@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-07arm64: dts: qcom: sc8180x-lenovo-flex-5g: Describe the display power netKonrad Dybcio
Describe and wire up the power supplies for the eDP panel and its backlight. Previously, this was only working because of settings inherited from the bootloader. Fixes: 20dea72a393c ("arm64: dts: qcom: sc8180x: Introduce Lenovo Flex 5G") Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260616-topic-8180_disp_power-v2-4-167785993231@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-05 16:36:26 +0000