summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-08media: ipu-bridge: Add Sony IMX471 for Lenovo X1 Carbon G14Kate Hsuan
The HID for Sony IMX471 is TBE20A0 on Lenovo X1 Carbon G14. Signed-off-by: Kate Hsuan <hpa@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-08media: ipu-bridge: Add DMI information of Lenovo X9 to the image upside-down ↵Kate Hsuan
list The Lenovo X9 has an upside-down-mounted Sony IMX471 sensor so the image was displayed upside-down. Add the DMI information of Lenovo X9 to resolve the issue. Signed-off-by: Kate Hsuan <hpa@redhat.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-07-08Merge tag 'for-net-2026-07-06' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - hci_conn: Fix null ptr deref in hci_abort_conn() - af_bluetooth: fix UAF in bt_accept_dequeue() - L2CAP: validate option length before reading conf opt value - L2CAP: cancel pending_rx_work before taking conn->lock - L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb() - L2CAP: fix tx ident leak for commands without a response - SCO: Fix a race condition in sco_sock_timeout() - ISO: avoid NULL deref of conn in iso_conn_big_sync() - ISO: fix malformed ISO_END/CONT handling - ISO: exclude RFU bits from ISO_SDU_Length - MGMT: Fix adv monitor add failure cleanup - MGMT: Fix UAF of hci_conn_params in add_device_complete - bnep: pin L2CAP connection during netdev registration - 6lowpan: avoid untracked enable work - 6lowpan: hold L2CAP conn across debugfs control - 6lowpan: Fix using chan->conn as indication to no remote netdev - btintel_pcie: Refactor FLR to use device_reprobe() - btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3() - hci_uart: clear HCI_UART_SENDING when write_work is canceled - bpa10x: avoid OOB read of revision string in bpa10x_setup() * tag 'for-net-2026-07-06' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: L2CAP: fix tx ident leak for commands without a response Bluetooth: bpa10x: avoid OOB read of revision string in bpa10x_setup() Bluetooth: ISO: exclude RFU bits from ISO_SDU_Length Bluetooth: ISO: fix malformed ISO_END/CONT handling Bluetooth: btintel_pcie: Refactor FLR to use device_reprobe() Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb() Bluetooth: fix UAF in bt_accept_dequeue() Bluetooth: bnep: pin L2CAP connection during netdev registration Bluetooth: sco: Fix a race condition in sco_sock_timeout() Bluetooth: MGMT: Fix adv monitor add failure cleanup Bluetooth: 6lowpan: hold L2CAP conn across debugfs control Bluetooth: 6lowpan: avoid untracked enable work Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn() Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3() Bluetooth: L2CAP: validate option length before reading conf opt value Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync() Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete Bluetooth: 6lowpan: Fix using chan->conn as indication to no remote netdev Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled ==================== Link: https://patch.msgid.link/20260706145229.728127-1-luiz.dentz@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08Merge branch 'net-dsa-microchip-move-non-common-function-out-of-ksz_common-c'Paolo Abeni
Bastien Curutchet says: ==================== net: dsa: microchip: move non-common function out of ksz_common.c This series continues the rework of the KSZ driver initiated by three previous series (see [1], [2] & [3]). The KSZ driver handles more than 20 switches split in several families. This was previously handled through a common set of dsa_switch_ops operations that used device-specific ksz_dev_ops callbacks. The three previous series have split this common struct dsa_switch_ops into 5 to connect the ksz_dev_ops's implentations directly to the new dsa_swicth ops. This series continues in the same vein and moves out of ksz_common.c all the functions that aren't truly common to all the families. On top of this on-going rework I added PTP and periodic output support for the KSZ8463 (which was my first goal). There are still more than 13 patches left for all this so this series will be followed by two others and if you want to see the full picture we can check my github ([4]). FYI, I only have a KSZ8463 so, unfortunately, I can't test other switches. The next series is going to add PTP support for the KSZ8463. The final one will add periodic output support for the KSZ8463. [1]: https://lore.kernel.org/r/20260505-clean-ksz-driver-v1-0-05d70fa42461@bootlin.com [2]: https://lore.kernel.org/r/20260521-clean-ksz-2nd-series-v3-0-75c38971c19a@bootlin.com [3]: https://lore.kernel.org/r/20260608-clean-ksz-3rd-v2-0-6e61b7be23c4@bootlin.com [4]: https://github.com/bastien-curutchet/linux/tree/ksz_rework Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> ==================== Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-0-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: move the drive strength config out of the common sectionBastien Curutchet (Schneider Electric)
The drive strength configuration is done during the setup of all switches through a common function that then has specific behavior depending on the switch identity. Split the common configuration in two functions: one is dedicated to the KSZ8 family, the other is dedicated to the KSZ9477 family. Remove the drive strength configuration from the lan937x_setup since the LAN937x family doesn't support it. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-10-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: rename ksz9477_drive_strength_write()Bastien Curutchet (Schneider Electric)
ksz9477_drive_strength_write() isn't used for the KSZ9477-family only. It's also used for the KSZ87xx chip variants. This function name is misleading. Rename it ksz_drive_strength_write(). Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-9-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: move ksz9477_set_default_prio_queue_mapping() to ksz9477.cBastien Curutchet (Schneider Electric)
ksz9477_set_default_prio_queue_mapping() dictates a KSZ9477-specific behavior but is defined in the common section of the code. Move its definition to the KSZ9477-specific area. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-8-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: handle KSZ8-specific tc setup in ksz8.cBastien Curutchet (Schneider Electric)
The setup of QDISC_ETS isn't the same for the KSZ8 switches than for the other switches. It leads to is_ksz8() branches in the common code. Move the KSZ8-specific portions into ksz8.c by creating two setup_tc() functions, one dedicated to the KSZ87xx family that only handles the TC_SETUP_QDISC_CBS case, one for the rest of the KSZ8 that handles both TC_SETUP_QDISC_CBS and TC_SETUP_QDISC_ETS cases. It remains some is_kszXXXX() branches because inside the ksz88xx family, only the ksz88x3 switches support QDISC_ETS. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-7-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: move KSZ9477 errata handling to ksz9477.cBastien Curutchet (Schneider Electric)
The KSZ9477 PHY errata is handled from the common ksz_r_mib_stat64(). This errata clearly belongs to the KSZ9477 family so it should be handled from the ksz9477-specific portion of the driver. Create a ksz9477-specific r_mib_stat64() implementation that handles this errata. Remove the errata handling from the common ksz_r_mib_stat64(). Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-6-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: move ksz_get_gbit() and ksz_get_xmii() to ksz9477.cBastien Curutchet (Schneider Electric)
ksz_get_gbit() and ksz_get_xmii() are defined in the ksz_common while they are only used by the ksz9477 driver. Move their definition into ksz9477.c Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-5-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: move ksz88xx stats handling in ksz8.cBastien Curutchet (Schneider Electric)
ksz88xx_r_mib_stats64() is defined in ksz_common while it's clearly ksz88xx-specific. Move its definition in ksz8.c Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-4-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-08net: dsa: microchip: make ksz_is_port_mac_global_usable() staticBastien Curutchet (Schneider Electric)
ksz_is_port_mac_global_usable() is exposed in ksz_common.h while it's only used internally. Make ksz_is_port_mac_global_usable() static. Move its definition above its first call. Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com> Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-3-93441e695fa4@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
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-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-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>