summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-06-04drm/amdgpu: deprecate guilty handlingChristian König
The guilty handling tried to establish a second way of signaling problems with the GPU back to userspace. This caused quite a bunch of issue we had to work around, especially lifetime issues with the drm_sched_entity. Just drop the handling altogether and use the dma_fence based approach instead. v2: fix reversed condition in entity check (Alex) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: Add lockdep annotations for lock ordering validationVitaly Prosyak
Add lockdep annotations to teach lockdep the correct lock hierarchy and catch ordering violations during development. This follows the pattern established by dma-resv in drivers/dma-buf/dma-resv.c. Lock ordering hierarchy (outermost to innermost): 1. userq_sch_mutex - Global userq scheduler (enforce_isolation) 2. userq_mutex - Per-context userq (held across queue create/destroy) 3. notifier_lock - MMU notifier synchronization 4. vram_lock - VRAM memory allocator 5. reset_domain->sem - GPU reset synchronization 6. reset_lock - Reset control mutex 7. srbm_mutex - SRBM register access 8. grbm_idx_mutex - GRBM index register access 9. mmio_idx_lock - MMIO index access (spinlock) The implementation provides: - Lock ordering training at module init (amdgpu_lockdep_init) - Lock class association for real driver locks (amdgpu_lockdep_set_class) Dummy locks are associated with the same class keys as real driver locks via lockdep_set_class(), ensuring lockdep connects the training ordering with actual runtime locks. Testing: Build the kernel with CONFIG_PROVE_LOCKING=y (enables CONFIG_LOCKDEP): scripts/config --enable PROVE_LOCKING scripts/config --enable DEBUG_LOCKDEP make -j$(nproc) On boot, dmesg should show: AMDGPU: Lockdep annotations initialized (9 lock levels) The companion IGT test (tests/amdgpu/amd_lockdep) exercises lock-heavy GPU code paths concurrently to trigger lockdep warnings on violations: sudo ./build/tests/amdgpu/amd_lockdep sudo dmesg | grep -A 50 "circular locking dependency" IGT subtests: concurrent-reset-and-submit - reset_sem vs submission locks concurrent-mmap-and-evict - mmap_lock vs vram_lock concurrent-userptr-and-reset - notifier_lock vs reset_sem stress-all-paths - all of the above simultaneously A clean dmesg (no "circular locking dependency" or "possible recursive locking detected" messages) confirms no lock ordering violations. For CI integration, the test should be run on kernels compiled with CONFIG_LOCKDEP=y; dmesg is scanned post-run for lockdep splats. v2: (Christian) - Move notifier_lock and vram_lock before reset locks in hierarchy. HMM invalidation holds notifier_lock and can wait for GPU reset completion, so notifier_lock must be outer to reset_domain->sem. - Associate dummy locks with lock class keys via lockdep_set_class() so lockdep connects training with real driver locks. - Update commit message to list all 9 lock levels. Requires CONFIG_PROVE_LOCKING=y to activate. Cc: Christian Konig <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com> Reviewed-by: Christian Konig <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdkfd: fix SMI event cross-process information leakYongqiang Sun
kfd_smi_ev_enabled() skips the suser privilege check when pid=0. PROCESS_START, PROCESS_END, and VMFAULT events are emitted with pid=0 while carrying another process's PID and command name, so any /dev/kfd user in the render group can monitor all GPU workloads. Pass the target process PID into kfd_smi_event_add() for these events so the existing per-client filter restricts delivery to the owning process or CAP_SYS_ADMIN subscribers. Signed-off-by: Yongqiang Sun <Yongqiang.Sun@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/display: Add DCN42B to dml21_translation_helperMatthew Stewart
Needed for DML to function with DCN42B. Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amd/display: Fix DCN42B version detectionMatthew Stewart
In resource_parse_asic_id, the check for GC_11_0_4 was unbounded, which caused it to override the detection of DCN42B. Signed-off-by: Matthew Stewart <Matthew.Stewart2@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04drm/amdgpu: Fix user-triggerable BUG()/BUG_ON() callsCe Sun
Replace BUG()/BUG_ON() with error logs and safe returns in several places where they can be triggered by invalid userspace input, preventing DoS via kernel panic. Signed-off-by: Ce Sun <cesun102@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-06-04rpmsg: char: Fix use-after-free on probe error pathYuho Choi
rpmsg_chrdev_probe() stores the newly allocated eptdev in the default endpoint's priv pointer before calling rpmsg_chrdev_eptdev_add(). If rpmsg_chrdev_eptdev_add() then fails, its error path frees eptdev while the default endpoint may still dispatch callbacks with the stale priv pointer. Avoid publishing eptdev through the default endpoint until rpmsg_chrdev_eptdev_add() succeeds. Messages received before the priv pointer is published should be ignored by rpmsg_ept_cb(). Flow-control updates can hit rpmsg_ept_flow_cb() in the same window, so make both callbacks return success when priv is NULL. Fixes: bc69d1066569 ("rpmsg: char: Introduce the "rpmsg-raw" channel") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20260601183247.1962010-1-dbgh9129@gmail.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-06-04net/mlx5: convert miss_list allocation to kvmalloc_array()William Theesfeld
dr_icm_buddy_init_ste_cache() allocates the per-buddy miss_list using the open-coded kvmalloc(n * sizeof(*p), ...) form. The neighbouring allocations in the same function already use the kvcalloc()/ kvzalloc_objs() forms; switch this last one to kvmalloc_array() for consistency and for the size_mul overflow check that kvmalloc_array() performs. The semantics are unchanged: kvmalloc_array() returns a non-zeroed buffer, just like the previous kvmalloc() call. Existing callers of buddy->miss_list initialise each list_head before use. Signed-off-by: William Theesfeld <william@theesfeld.net> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260601193758.626537-1-william@theesfeld.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04power: supply: add support for Samsung S2M series PMIC charger deviceKaustabh Chakraborty
Add a driver for charger controllers found in certain Samsung S2M series PMICs. The driver has very basic support for the device, with only charger online reporting working, and USB 2.0 device negotiations working. The driver includes initial support for the S2MU005 PMIC charger. Co-developed-by: Łukasz Lebiedziński <kernel@lvkasz.us> Signed-off-by: Łukasz Lebiedziński <kernel@lvkasz.us> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org> Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-10-73f9702fb461@disroot.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-04Reapply "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"Jakub Kicinski
This reverts commit 850d9248d2eac662f869c766a598c877690c74e5. This reapplies commit 325eb217e41f ("bnxt_en: bring back rtnl_lock() in the bnxt_open() path"). Breno reports a lockdep warning in bnxt. During FW reset the driver may end up calling netif_set_real_num_tx_queues() (if queue count changes), so calls to bnxt_open() still require rtnl_lock. net/sched/sch_generic.c:1416 suspicious rcu_dereference_protected() usage! dev_qdisc_change_real_num_tx+0x54/0xe0 netif_set_real_num_tx_queues+0x4ed/0xa80 __bnxt_open_nic+0x9cb/0x3490 bnxt_open+0x1cb/0x370 bnxt_fw_reset_task+0x80d/0x1e80 process_scheduled_works+0x9c1/0x13b0 The reverted commit was just an optimization / experiment so let's go back to taking the lock. Reported-by: Breno Leitao <leitao@debian.org> Link: https://lore.kernel.org/ah726OtFX-Qw3U-R@gmail.com Fixes: 850d9248d2ea ("Revert "bnxt_en: bring back rtnl_lock() in the bnxt_open() path"") Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260603195845.2574426-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04regulator: bq257xx: drop confusing configuration of_nodeJohan Hovold
The driver reuses the OF node of the parent multi-function device but still sets the of_node field of the regulator configuration to any prior OF node. Since the MFD child device does not have an OF node set until probe is called, this field is set to NULL on first probe and to the reused OF node if the driver is later rebound. As the device_set_of_node_from_dev() helper drops a reference to any prior OF node before taking a reference to the new one this can apparently also confuse LLMs like Sashiko which flags it as a potential use-after-free (which it is not). Drop the confusing and redundant configuration of_node assignment. Link: https://sashiko.dev/#/patchset/20260408073055.5183-1-johan%40kernel.org Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260604115912.2734074-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-04bonding: annotate data-races arcound churn variablesEric Dumazet
These fields are updated asynchronously by the bonding state machine in ad_churn_machine() while holding bond->mode_lock. bond_info_show_slave() and bond_fill_slave_info() read them without bond->mode_lock being held, we need to add READ_ONCE() and WRITE_ONCE() annotations. Note that AD_CHURN_MONITOR, AD_CHURN, and AD_NO_CHURN are defined exclusively in (kernel private) include/net/bond_3ad.h header. They should be moved to include/uapi/linux/if_bonding.h or userspace tools will have to hardcode their values. Fixes: 4916f2e2f3fc ("bonding: print churn state via netlink") Fixes: 14c9551a32eb ("bonding: Implement port churn-machine (AD standard 43.4.17).") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260603123514.388226-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04rtase: Avoid sleeping in get_stats64()Justin Lai
The .ndo_get_stats64 callback must not sleep because it can be called when reading /proc/net/dev. rtase_get_stats64() calls rtase_dump_tally_counter(), which polls the tally counter dump bit with read_poll_timeout(). This may sleep while waiting for the hardware counter dump to complete. Use read_poll_timeout_atomic() instead to avoid sleeping in the get_stats64() path. Fixes: 079600489960 ("rtase: Implement net_device_ops") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai <justinlai0215@realtek.com> Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04vxlan: vnifilter: fix spurious notification on VNI updateAndy Roulin
When a VNI is re-added with the same attributes (e.g. same group or no group), vxlan_vni_update() sends a spurious RTM_NEWTUNNEL notification even though nothing changed. The bug is that 'if (changed)' tests whether the pointer is non-NULL, not the bool value it points to. Since every caller passes a valid pointer, the condition is always true and the notification fires unconditionally. Fix by dereferencing the pointer: 'if (*changed)'. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # bridge vni add vni 1000 dev vxlan100 # spurious notification Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Signed-off-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260602185138.253265-3-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04vxlan: vnifilter: send notification on VNI addAndy Roulin
When a new VNI is added to a vxlan device with vnifilter enabled, no RTM_NEWTUNNEL notification is sent to userspace. This means 'bridge monitor vni' never shows VNI add events, even though VNI delete events are reported correctly. The bug is in vxlan_vni_add(), where the notification is guarded by 'if (changed)'. The 'changed' flag is set by vxlan_vni_update_group() only when the multicast group or remote IP is modified, but for a new VNI added without a group (e.g. in L3 VxLAN interface scenarios), the function returns early without setting changed=true. Since this is a new VNI, the notification should be sent unconditionally. The notification is not guarded by the return value of vxlan_vni_update_group() because, at this point, the VNI has already been inserted into the hash table and list with no rollback on error. The VNI will be visible in 'bridge vni show' regardless, so userspace should be informed. This is consistent with vxlan_vni_del() which also notifies unconditionally. The 'if (changed)' guard remains correct in vxlan_vni_update(), which handles the case where a VNI already exists and is being re-added -- there, we only want to notify if the group/remote actually changed. Reproducer: # ip link add vxlan100 type vxlan dstport 4789 local 10.0.0.1 \ nolearning external vnifilter # ip link set vxlan100 up # bridge monitor vni & # bridge vni add vni 1000 dev vxlan100 # no notification # bridge vni delete vni 1000 dev vxlan100 # notification received Fixes: f9c4bb0b245c ("vxlan: vni filtering support on collect metadata device") Reported-by: Chirag Shah <chirag@nvidia.com> Signed-off-by: Andy Roulin <aroulin@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Link: https://patch.msgid.link/20260602185138.253265-2-aroulin@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04cxl/fwctl: Fix __fortify_panicDan Williams
Fix a runtime assertion in cxlctl_get_supported_features(). Fortify complains that it is potentially overflowing the entries array per __counted_by_le(num_entries). Quiet the false positive by initializing @num_entries earlier. memcpy: detected buffer overflow: 48 byte write of buffer size 0 WARNING: lib/string_helpers.c:1036 at __fortify_report+0x4d/0xa0, CPU#7: fwctl/1398 RIP: 0010:__fortify_report+0x50/0xa0 Call Trace: __fortify_panic+0xd/0xf cxlctl_get_supported_features.cold+0x23/0x35 [cxl_core] Fixes: 4d1c09cef2c2 ("cxl: Add support for fwctl RPC command to enable CXL feature commands") Signed-off-by: Dan Williams <djbw@kernel.org> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260519221204.1517773-2-djbw@kernel.org Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-04cxl/region: Validate partition index before array accessKoba Ko
construct_region() reads cxled->part and uses it to index cxlds->part[] without checking for a negative value. If the partition was never resolved, part remains at its initial value of -1, causing an out-of-bounds array access. Add a guard to return -EBUSY when part is negative. The check was dropped during a merge. Signed-off-by: Koba Ko <kobak@nvidia.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260414024527.3399590-1-kobak@nvidia.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-04cxl/memdev: Hold memdev lock during memdev poison injection/clearLi Ming
cxl_dpa_to_region() assumes that it is running a context where it is not racing changes to "cxlmd->dev.driver". Acquire the memdev device lock in the debugfs entry points to preclude debugfs usage racing cxl_mem driver detach. Suggested-by: Dan Williams <djbw@kernel.org> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dan Williams <djbw@kernel.org> Signed-off-by: Li Ming <ming.li@zohomail.com> Link: https://patch.msgid.link/20260423111949.177399-1-ming.li@zohomail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-06-04rtase: Reset TX subqueue when clearing TX ringJustin Lai
rtase_tx_clear() clears the TX ring and resets the ring indexes. However, the TX queue state and BQL accounting are not reset at the same time. This may leave __QUEUE_STATE_STACK_XOFF asserted after rtase_sw_reset(), preventing new TX packets from being scheduled. Reset the TX subqueue when clearing the TX ring so the TX queue state and BQL accounting are restored together. Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function") Cc: stable@vger.kernel.org Signed-off-by: Justin Lai <justinlai0215@realtek.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04octeontx2-af: npc: Fix CPT channel mask in npc_install_flowNithin Dabilpuram
Use the CPT-aware NIX channel mask in the npc_install_flow path so that when the host PF installs steering rules in kernel for a VF used from userspace (e.g. DPDK), MCAM entries see the same channel mask semantics as other RX paths. Fixes: 56bcef528bd8 ("octeontx2-af: Use npc_install_flow API for promisc and broadcast entries") Cc: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Nithin Dabilpuram <ndabilpuram@marvell.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260602045853.1558530-1-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Set the Link End (LE) bit on the last descriptorClaudiu Beznea
On an RZ/G2L-based system, it has been observed that when the DMA channels for all enabled IPs are active (TX and RX for one serial IP, TX and RX for one audio IP, and TX and RX for one SPI IP), shortly after all of them are started, the system can become irrecoverably blocked. In one debug session the system did not block, and the DMA HW registers were inspected. It was found that the DER (Descriptor Error) bit in the CHSTAT register for one of the SPI DMA channels was set. According to the RZ/G2L HW Manual, Rev. 1.30, chapter 14.4.7 Channel Status Register n/nS (CHSTAT_n/nS), description of the DER bit, the DER bit is set when the LV (Link Valid) value loaded with a descriptor in link mode is 0. This means that the DMA engine has loaded an invalid descriptor (as defined in Table 14.14, Header Area, of the same manual). The same chapter states that when a descriptor error occurs, the transfer is stopped, but no DMA error interrupt is generated. Set the LE bit on the last descriptor of a transfer. This informs the DMA engine that this is the final descriptor for the transfer. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-19-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add suspend to RAM supportClaudiu Beznea
The Renesas RZ/G3S SoC supports a power saving mode in which power to most of the SoC components is turned off, including the DMA IP. Add suspend to RAM support to save and restore the DMA IP registers. Cyclic DMA channels require special handling. Since they can be paused and resumed during system suspend/resume, the driver restores additional registers for these channels during the system resume phase. If a channel was not explicitly paused during suspend, the driver ensures that it is paused and resumed as part of the system suspend/resume flow. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-16-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add runtime PM supportClaudiu Beznea
Protect the driver exposed APIs with runtime PM suspend/resume calls before accessing HW registers. As the current driver leaves runtime PM enabled in probe, the purpose of the changes in this patch is to avoid accessing HW registers after a failed system suspend leaves the runtime PM state of the device improperly reinitialized. In that case, the driver remains bound to the device, the APIs are still exposed, and any access to HW registers without runtime resuming the device may lead to synchronous aborts. To avoid leaking resources in case of runtime PM failures, save the error code returned by PM_RUNTIME_ACQUIRE_ERR() in rz_dmac_terminate_all() and return it only at the end of the function to allow the cleanup code to run. A similar approach is used in rz_dmac_free_chan_resources(). Because some exposed APIs (e.g. ->device_terminate_all()) may be called from atomic context according to the documentation, mark the DMA device as pm_runtime_irq_safe(). This patch prepares the driver for suspend-to-RAM support. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-15-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Adjust rz_dmac_chan_get_residue() to return error codesClaudiu Beznea
Adjust rz_dmac_chan_get_residue() to return error codes on failure and provide the residue to callers through the residue parameter. This prepares the code for the addition of runtime PM support. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-14-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add cyclic DMA supportClaudiu Beznea
Add cyclic DMA support to the RZ DMAC driver. A per-channel status bit is introduced to mark cyclic channels and is set during the DMA prepare callback. The IRQ handler checks this status bit and calls vchan_cyclic_callback() accordingly. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-13-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Drop the update of channel->chctrl with CHCTRL_SETENClaudiu Beznea
The CHCTRL_SETEN bit is explicitly set in rz_dmac_enable_hw(). Updating struct rz_dmac_chan::chctrl with this bit in rz_dmac_prepare_desc_for_memcpy() and rz_dmac_prepare_descs_for_slave_sg() is unnecessary in the current code base. Moreover, it conflicts with the configuration sequence that will be used for cyclic DMA channels during suspend to RAM. Cyclic DMA support will be introduced in subsequent commits. This is a preparatory commit for cyclic DMA suspend to RAM support. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-12-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Refactor pause/resume codeClaudiu Beznea
Subsequent patches will add suspend/resume and cyclic DMA support to the rz-dmac driver. This support needs to work on SoCs where power to most components (including DMA) is turned off during system suspend. For this, some channels (for example cyclic ones) may need to be paused and resumed manually by the DMA driver during system suspend/resume. Refactor the pause/resume support so the same code can be reused in the system suspend/resume path. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-11-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Use virt-dma APIs for channel descriptor processingClaudiu Beznea
The driver used a mix of virt-dma APIs and driver specific logic to process descriptors. It maintained three internal queues: ld_free, ld_queue, and ld_active as follows: - ld_free: stores the descriptors pre-allocated at probe time - ld_queue: stores descriptors after they are taken from ld_free and prepared. At the same time, vchan_tx_prep() queues them to vc->desc_allocated. The vc->desc_allocated list is then checked in rz_dmac_issue_pending() and rz_dmac_irq_handler_thread() before starting a new transfer via rz_dmac_xfer_desc(). In turn, rz_dmac_xfer_desc() grabs the next descriptor from vc->desc_issued and submits it for transfer - ld_active: stores the descriptors currently being transferred The interrupt handler moved a completed descriptor to ld_free before invoking its completion callback. Once returned to ld_free, the descriptor can be reused to prepare a new transfer. In theory, this means the descriptor could be re-prepared before its completion callback is called. Commit fully back the driver by the virt-dma APIs. With this, only ld_free need to be kept to track how many free descriptors are available. This is now done as follows: - the prepare stage removes the first descriptor from the ld_free and prepares it - the completion calls for it vc->desc_free() (rz_dmac_virt_desc_free()) which re-adds the descriptor at the end of ld_free With this, the critical areas in prepare callbacks were minimized to only getting the descriptor from the ld_free list. Introduce struct rz_dmac_chan::desc to keep track of the currently transferred descriptor. It is cleared in rz_dmac_terminate_all(), referenced from rz_dmac_issue_pending() to determine whether a new transfer can be started, and from rz_dmac_irq_handler_thread() once a descriptor has completed. Finally, the rz_dmac_device_synchronize() was updated with vchan_synchronize() call to ensure the terminated descriptor is freed and the tasklet is killed. With this, residue computation is also simplified, as it can now be handled entirely through the virt-dma APIs. The spin_lock/unlock operations from rz_dmac_irq_handler_thread() were replaced by guard as the final code after rework is simpler this way. As subsequent commits will set the Link End bit on the last descriptor of a transfer, rz_dmac_enable_hw() is also adjusted as part of the full conversion to virt-dma APIs. It no longer checks the channel enable status itself; instead, its callers verify whether the channel is enabled and whether the previous transfer has completed before starting a new one. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-10-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to check if the channel is pausedClaudiu Beznea
Add the rz_dmac_chan_is_paused() helper to check if the channel is paused. This helper will be reused in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-9-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to check if the channel is enabledClaudiu Beznea
Add the rz_dmac_chan_is_enabled() helper to check if a channel is enabled. This helper will be reused in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-8-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Save the start LM descriptorClaudiu Beznea
Save the start LM descriptor to avoid starting from the beginning of the channel's LM descriptor list in rz_dmac_calculate_residue_bytes_in_vd(). This avoids unnecessary iterations. Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-7-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Add helper to compute the lmdesc addressClaudiu Beznea
Add a the rz_dmac_lmdesc_addr() helper function to compute the lmdesc address, to make the code easier to understand. The helper will be used in subsequent patches. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-6-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Use rz_dmac_disable_hw()Claudiu Beznea
Use rz_dmac_disable_hw() instead of open coding it. This unifies the code and prepares it for the addition of suspend to RAM and cyclic DMA. The rz_dmac_disable_hw() from rz_dmac_chan_probe() was moved after vchan_init() as it initializes the channel->vc.chan.device used in rz_dmac_disable_hw(). Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-5-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Use list_first_entry_or_null()Claudiu Beznea
Use list_first_entry_or_null() instead of open-coding it with a list_empty() check and list_first_entry(). This simplifies the code. Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-4-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Fix incorrect NULL check for list_first_entry()Claudiu Beznea
list_first_entry() does not return NULL when the list is empty, making the existing NULL check invalid. Use list_first_entry_or_null() instead. Fixes: 21323b118c16 ("dmaengine: sh: rz-dmac: Add device_tx_status() callback") Cc: stable@vger.kernel.org Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-3-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04dmaengine: sh: rz-dmac: Move interrupt request after everything is set upClaudiu Beznea
Once the interrupt is requested, the interrupt handler may run immediately. Since the IRQ handler can access channel->ch_base, which is initialized only after requesting the IRQ, this may lead to invalid memory access. Likewise, the IRQ thread may access uninitialized data (the ld_free, ld_queue, and ld_active lists), which may also lead to issues. Request the interrupts only after everything is set up. To keep the error path simpler, use dmam_alloc_coherent() instead of dma_alloc_coherent(). Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: John Madieu <john.madieu.xa@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260526084710.3491480-2-claudiu.beznea@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-06-04PCI: qcom: Initialize DWC MSI lock for firmware-managed ECAM hostsYadu M G
A lockdep warning is observed during boot on a Qcom firmware-managed platform: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. ... Call trace: register_lock_class+0x128/0x4d8 __lock_acquire+0x110/0x1db0 lock_acquire+0x278/0x3d8 _raw_spin_lock_irq+0x6c/0xc0 dw_pcie_irq_domain_alloc+0x48/0x190 irq_domain_alloc_irqs_parent+0x2c/0x48 msi_domain_alloc+0x90/0x160 ... dw_pcie_irq_domain_alloc() takes pp->lock while allocating MSI interrupts. pp->lock is normally initialized by dw_pcie_host_init(), but Qcom firmware-managed hosts use the ECAM init path instead: pci_host_common_ecam_create() pci_ecam_create() qcom_pcie_ecam_host_init() dw_pcie_msi_host_init() dw_pcie_allocate_domains() That path constructs a fresh struct dw_pcie_rp and calls dw_pcie_msi_host_init() directly, without going through dw_pcie_host_init(). As a result, pp->lock was not initialized, which triggers the warning. Initialize pp->lock in qcom_pcie_ecam_host_init() before registering the MSI domains so the firmware-managed ECAM path matches the normal DWC host initialization sequence. Fixes: 7d944c0f1469 ("PCI: qcom: Add support for Qualcomm SA8255p based PCIe Root Complex") Signed-off-by: Yadu M G <yadu.mg@oss.qualcomm.com> [mani: added fixes tag and CCed stable] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Cc: stable@kernel.org Link: https://patch.msgid.link/20260604122418.727274-1-yadu.mg@oss.qualcomm.com
2026-06-04power: supply: Add support for Surface RT battery and chargerJonas Schwöbel
Add support for Embedded Controller found in the Microsoft Surface RT and used to monitor battery cell and charger input status and properties. Controller works both for UEFI and APX booting. [wmjb: added POWER_SUPPLY_PROP_CHARGE_NOW support] Signed-off-by: Jethro Bull <jethrob@hotmail.com> Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://patch.msgid.link/20260507134608.76222-3-clamor95@gmail.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-06-04drm/v3d: Fix global performance monitor reference countingMaíra Canal
In the SET_GLOBAL ioctl, v3d_perfmon_find() bumps the reference count on the perfmon it returns, but v3d_perfmon_set_global_ioctl() and v3d_perfmon_delete() fail to release that reference on several paths: 1. v3d_perfmon_set_global_ioctl() leaks the reference on its error paths. 2. CLEAR_GLOBAL leaks both the find reference and the reference previously stashed in v3d->global_perfmon by the SET_GLOBAL ioctl that configured it. 3. Destroying a perfmon that is the current global perfmon leaks the reference stashed by the SET_GLOBAL ioctl. Release each of these references explicitly. Cc: stable@vger.kernel.org Fixes: c6eabbab359c ("drm/v3d: Add DRM_IOCTL_V3D_PERFMON_SET_GLOBAL") Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Link: https://patch.msgid.link/20260531-v3d-perfmon-lifetime-v2-1-60ed4485a203@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-06-04gpio: remove obsolete UAF FIXMEs from lookup pathsMarco Scardovi (scardracs)
The ACPI and swnode GPIO lookup backends both temporarily grab a reference to the gpio_device, resolve the descriptor, and then drop the reference before returning the descriptor to the caller. They carry FIXME comments warning that the descriptor is being returned without its backing device reference. However, the gpiod_find_and_request() core functionally prevents any use-after-free window by wrapping the entire lookup operation inside the gpio_devices_srcu read lock. The lookup functions are correct to drop their references since the caller (gpiod_request) will subsequently take its own permanent module and device references safely. Remove these obsolete FIXMEs to prevent misleading future subsystem developers. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260524162708.62949-3-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-04gpio: core: fix const-correctness of gpio_chip_guardMarco Scardovi (scardracs)
The DEFINE_CLASS macro for gpio_chip_guard currently expects a non-const struct gpio_desc pointer. This prevents the guard from being used cleanly in fast paths that receive a const descriptor, forcing developers to fall back to open-coding the SRCU locks. Update the macro to accept a const struct gpio_desc pointer. This is valid because the actual targeted gpio_device pointer assignment does not drop const qualifiers on the target structure. Convert the open-coded SRCU locks in gpiod_get_raw_value_commit() and gpiod_to_irq() to use the guard, removing their legacy FIXME comments. Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260524162708.62949-2-scardracs@disroot.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-06-04drm/xe/multi_queue: skip submit when primary queue is suspendedNiranjana Vishwanathapura
Return early in submit path when the multi-queue primary exec queue is suspended to avoid submitting while suspended. v2: Remove idle_skip_suspend fix as that feature is being reverted here https://patchwork.freedesktop.org/series/167262/ Fixes: bc5775c59258 ("drm/xe/multi_queue: Add GuC interface for multi queue support") Cc: stable@vger.kernel.org # v7.0+ Assisted-by: GitHub-Copilot:claude-sonnet-4.6 Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Link: https://patch.msgid.link/20260603233946.863663-2-niranjana.vishwanathapura@intel.com (cherry picked from commit b7fb55cc3364ca128cfff9d50649ffd4327cd01e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04drm/xe: Clear pending_disable before signaling suspend fenceTangudu Tilak Tirumalesh
In the schedule-disable done path for suspend, we signal the suspend fence before clearing pending_disable. That wakeup can let suspend_wait complete and resume be queued immediately. The resume path may then reach enable_scheduling() while pending_disable is still set and hit the !exec_queue_pending_disable(q) assertion. Fix this by clearing pending_disable before signaling the suspend fence, so any resumed transition observes a consistent state. Fixes: 87651f31ae4e ("drm/xe/guc_submit: fix race around suspend_pending") Cc: stable@vger.kernel.org # v7.0+ Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260603065217.3131066-3-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 4b1ae138b0e103d753773956a84eebc2edbf62c4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04Revert "drm/xe: Skip exec queue schedule toggle if queue is idle during suspend"Tangudu Tilak Tirumalesh
This reverts commit 8533051ce92015e9cc6f75e0d52119b9d91610b6. The idle-skip optimization bypasses GuC suspend, so the GPU may not perform the context switch that flushes TLB entries for invalidated userptr VMAs. In LR/preempt-fence VM mode, this can lead to missed TLB invalidation and page faults during userptr invalidation tests. Restore unconditional schedule toggling on suspend so the context-switch TLB flush is always performed. This optimization will be reintroduced with a fix that does not skip suspend in LR/preempt-fence VM mode. Fixes: 8533051ce920 ("drm/xe: Skip exec queue schedule toggle if queue is idle during suspend") Cc: stable@vger.kernel.org # v7.0+ Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260603065217.3131066-2-tilak.tirumalesh.tangudu@intel.com (cherry picked from commit 6a1e7934d9a6cf46aecae00a99c2603d1295e170) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-06-04Merge tag 'iwlwifi-next-2026-06-03' of ↵Johannes Berg
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Miri Korenblit says: ==================== wifi: iwlwifi-next : updates - 2026-06-03 This pull request contains iwlwifi features and cleanups. Notably: - Bump max core version for BZ/SC/DR to 106. - Add KUnit tests for link grading, RSSI adjustment, and beacon handling; - Drop core101 support and remove TLC config v4/v5 compatibility code. - Fixes: Fix PCIe write pointer detection Fix STEP_URM register address Remove unneeded WoWLAN warning reduce NIC wakeups during dump. Revert MODULE_FIRMWARE relocation change ==================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04Merge tag 'ath-next-20260602' of ↵Johannes Berg
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath Jeff Johnson says: ================== ath.git patches for v7.2 (PR #3) In ath12k, add driver support for WDS mode. In ath11k and ath12k, a number of cleanups and minor bug fixes. ================== Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04wifi: wlcore: enable the right set of ciphersAndreas Kemnade
The firmware version number check for IGTK introduced in commit c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") lets the amount of ciphers decrease on every boot of a too old firmware and that is practically happening. It also does not take into account other chips than the wl18xx. On some wl128x, the following can be observed when connecting via nm to a common ap: [ 484.113311] wlcore: WARNING could not set keys [ 484.117828] wlcore: ERROR Could not add or replace key [ 484.123016] wlan0: failed to set key (5, ff:ff:ff:ff:ff:ff) to hardware (-5) [ 484.123046] wlcore: Hardware recovery in progress. FW ver: Rev 7.3.10.0.142 [ 484.139923] wlcore: pc: 0x0, hint_sts: 0x00000048 count: 1 [ 484.145721] wlcore: down [ 484.148986] ieee80211 phy0: Hardware restart was requested [ 484.610473] wlcore: firmware booted (Rev 7.3.10.0.142) [ 484.633758] wlcore: Association completed. [ 484.690490] wlcore: ERROR command execute failure 14 [ 484.690490] ------------[ cut here ]------------ [ 484.700195] WARNING: drivers/net/wireless/ti/wlcore/main.c:872 at wl12xx_queue_recovery_work+0x64/0x74 [wlcore], CPU#0: kworker/0:0/892 This repeats endlessly. Always disable IGTK on wl12xx and fix the decrementing mess. Fixes: c34dbc5900b0 ("wifi: wlcore: Add support for IGTK key") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Link: https://patch.msgid.link/20260604103316.377251-1-andreas@kemnade.info Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-06-04ipmi: si: Use platform_get_irq_optional() to retrieve interruptRosen Penev
Use platform_get_irq_optional() to retrieve the interrupt resource instead of directly parsing and mapping the OF node via irq_of_parse_and_map(). This is the standard pattern for platform devices. irq_of_parse_and_map() requires ire_dispose_mapping(), which is missing. Assisted-by: Antigravity:Gemini-3.5-Flash Signed-off-by: Rosen Penev <rosenp@gmail.com> Message-ID: <20260603192511.6869-1-rosenp@gmail.com> [Handle a negative return from platform_get_irq_optional() to mean no interrupt is assigned.] Signed-off-by: Corey Minyard <corey@minyard.net>
2026-06-04spi: cadence-xspi: Support 32bit and 64bit slave dma interfaceJisheng Zhang
The cdns xspi controller slave dma interface may support wider data width. Wider I/O width can benefit performance. We can know the width by checking the CTRL_FEATURES_REG's DMA_DATA_WIDTH bit, 0 means 32bit 1 means 64bit. A simple test with QSPI nor flash on one arm64 platform: Use 8bit slave dma data width (now): # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 1.368735 seconds, 5.7MB/s Use 32bit slave dma data width: # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 1.088787 seconds, 7.2MB/s Improved by 26.3%! Use 64bit slave dma data width: # dd if=/dev/mtdblock0 of=/dev/null bs=8192 count=1000 1000+0 records in 1000+0 records out 8192000 bytes (7.8MB) copied, 0.831104 seconds, 9.4MB/s Improved by 64.9%! Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20260602235825.28614-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-06-04net: bonding: fix NULL pointer dereference in bond_do_ioctl()ZhaoJinming
In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check. Fixes: e2a7420df2e0 ("bonding/main: convert to using slave printk macros") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com> Link: https://patch.msgid.link/20260601085649.4029067-1-zhaojinming@uniontech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-07-08 19:39:29 +0000