summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-21dmaengine: dw-edma-pcie: Track non-LL mode in DMA dataKoichiro Den
The dw-edma-pcie driver copies static template data into a mutable dw_edma_pcie_data instance before applying capability-derived updates. Keep the derived non-LL mode in that copy as well, instead of only tracking it in a local variable in dw_edma_pcie_probe(). This prepares for keeping capability parsing behind match data without a separate non-LL output parameter. No functional change intended. Suggested-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-7-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21dmaengine: dw-edma: Add partial channel ownership modeKoichiro Den
A DesignWare eDMA instance may represent only a subset of channels that is also initialized by another OS instance, such as an endpoint-side OS. Add a partial ownership flag for instances that must preserve controller-wide state owned by that peer. In partial ownership mode, dw-edma skips the initial core reset and uses the limited quiesce path in probe() and remove() instead of the full core-off path. The flag also makes the driver validate the ownership granularity required by each register layout before registering channels. Probe fails if the limited quiesce cannot stop its resources; remove reports the error after completing the remaining driver teardown. Partial instances also skip interrupt-emulation doorbell allocation: the emulated doorbell is a controller-level resource, and a partial owner must not claim it on behalf of the whole block. For EDMA_MF_EDMA_UNROLL and EDMA_MF_HDMA_COMPAT, the driver programs per-direction registers, such as DMA_{WRITE,READ}_INT_MASK_OFF and DMA_{WRITE,READ}_INT_CLEAR_OFF. These register layouts have at most EDMA_MAX_{WR,RD}_CH channels per direction, so the capped hardware channel count still represents the whole direction. A partial instance can therefore expose write or read channels only if it owns every channel in that direction; otherwise two OS instances could update the same direction-wide registers without a shared locking protocol. In contrast, HDMA native uses per-channel registers, so it can be owned at channel granularity. Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-6-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21dmaengine: dw-edma: Initialize IRQ data before requesting IRQsKoichiro Den
dw_edma_irq_request() passes struct dw_edma_irq to request_irq() before dw_edma_channel_setup() fills the back pointer. A shared interrupt can therefore enter the handler with dw_irq->dw still NULL, leading to a NULL pointer dereference. Set the back pointer before installing each handler. Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-5-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21dmaengine: dw-edma: Add core quiesce operationsKoichiro Den
Add core operations that quiesce only the resources represented by a dw-edma instance, separate from the existing full controller off path. For unrolled eDMA, quiesce masks the direction, disables ENGINE_EN, waits for it to read back clear, then clears pending interrupt status. If ENGINE_EN does not clear, return the timeout to the caller. HDMA compatibility mode does not implement ENGINE_EN, so quiesce clears CHi_PWR_EN for each represented channel instead. Both register maps share interrupt control per direction, so quiescing one channel quiesces the whole direction. Callers must own that direction and stop the peer from programming it first. HDMA native has per-channel registers and can quiesce the represented channel directly. No caller is added yet, so this is a no-functional-change preparation for delegated channel reclaim and partial-owned remove paths. Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-4-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21dmaengine: dw-edma: Add per-channel interrupt routing controlKoichiro Den
DesignWare eDMA can signal completion locally through edma_int[] and remotely through IMWr/MSI. When channels are delegated to a remote frontend, the local endpoint side and the remote host side must not both service the same DONE/ABORT status. Add channel interrupt routing state and initialize it from the controller instance configuration. Update the eDMA and HDMA native paths so linked-list interrupt generation, HDMA non-linked-list interrupt enables, and DONE/ABORT masking follow the selected mode. For HDMA native non-linked-list channels, keep the local stop/abort enables set so status is latched. In remote mode, also enable remote signaling and mask the local interrupt pins. Keep the existing dw-edma-pcie host-side instances in remote interrupt routing mode so their IMWr/MSI completion model remains unchanged after local routing becomes the zero value. Note: - The routing mode describes where a channel should report completion. It does not by itself say whether this dw-edma instance owns the interrupt status. A local instance must ignore remote-only channels, and a remote instance must ignore local-only channels, even if such interrupts are unexpectedly delivered. Otherwise the non-owner side could steal the interrupt from the owner by clearing shared DONE/ABORT status. Cc: Devendra K Verma <devendra.verma@amd.com> Suggested-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-3-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21dmaengine: dw-edma: Factor out HDMA interrupt setup helperKoichiro Den
The HDMA linked-list and non-linked-list start paths both program the stop/abort interrupt setup register using the same local/remote enable policy. Only the interrupt-mask handling differs by transfer mode. Factor the common setup into dw_hdma_v0_core_int_setup() before adding per-channel interrupt routing support. No functional change intended. Suggested-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Koichiro Den <den@valinux.co.jp> Link: https://patch.msgid.link/20260721062815.4117887-2-den@valinux.co.jp Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-21Merge tag 'kvm-riscv-fixes-7.2-1' of https://github.com/kvm-riscv/linux into ↵Paolo Bonzini
HEAD KVM/riscv fixes for 7.2, take #1 - Avoid redundant page-table allocations in ioremap pcache topup - Apply SBI FWFT LOCK flag only on successful set - Bound SBI PMU counter mask scan to BITS_PER_LONG - Skip TLB flush when G-stage PTE becomes valid with Svvptc - Zicbo[m|z|p] block sizes should be always present in ONE_REG - Inject instruction access fault on unmapped guest fetch - Serialize virtual interrupt pending state updates using raw spinlock - Fix Spectre-v1 in vector register access via ONE_REG
2026-07-21KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUNVenkatesh Srinivas
On Intel platforms with a VMX preemption timer and APICv, if a VMM calls KVM_GET_LAPIC before KVM_GET_MSRS to save the vCPU state, it is possible to lose a pending timer interrupt. If the thread running these ioctls is migrated to another core after calling KVM_GET_LAPIC but before KVM_GET_MSRS and the guest is using their LAPIC timer in TSC-deadline mode, not only does the save LAPIC state not carry the pending interrupt, the TSCDEADLINE MSR will be zeroed. After migration across CPUs, KVM_GET_MSRS calls vcpu_load, posting the interrupt and clearing the MSR: vcpu_load() -> kvm_arch_vcpu_load() -> kvm_lapic_restart_hv_timer() -> start_hv_timer() -> apic_timer_expired() -> kvm_apic_inject_pending_timer_irqs() . post interrupt into the LAPIC state . clear IA32_TSCDEADLINE The saved LAPIC state will be missing the pending interrupt and the saved MSR will be zero. Oops. Fix by only posting an interrupt when we're attempting to enter the guest (vcpu->wants_to_run == true), not for vcpu_load from other paths. Assisted-by: gemini:gemini-3.1-pro-preview Debugged-by: David Matlack <dmatlack@google.com> Debugged-by: Sean Christopherson <seanjc@google.com> Debugged-by: Jim Mattson <jmattson@google.com> Debugged-by: James Houghton <jthoughton@google.com> Signed-off-by: Venkatesh Srinivas <venkateshs@chromium.org> Message-ID: <20260715234234.15382-2-venkateshs@chromium.org> Reviewed-by: James Houghton <jthoughton@google.com> Reviewed-by: Chao Gao <chao.gao@intel.com> Cc: stable@vger.kernel.org Fixes: ae95f566b3d2 ("KVM: X86: TSCDEADLINE MSR emulation fastpath", 2020-05-15) Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: selftests: sev_init2_tests: Derive SEV availability from KVMDavid Woodhouse
The test asserted that the X86_FEATURE_SEV CPUID bit exactly matches whether KVM offers KVM_X86_SEV_VM. That is not an invariant: when all SEV ASIDs are assigned to SEV-SNP, KVM does not offer the SEV VM type even though CPUID reports SEV, so the test aborts on an SNP-only host. Derive SEV availability from KVM_CAP_VM_TYPES (as already done for SEV-ES and SNP), assert only the one-way implication that a type offered by KVM is also reported in CPUID, and TEST_REQUIRE() the SEV VM type so the test skips cleanly when it is unavailable. Reviewed-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-ID: <5d3c345113748f39b7982e365d241abaf3e11086.1784545391.git.dwmw@amazon.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: selftests: sev_smoke_test: Only run VM types the host offersDavid Woodhouse
sev_smoke_test ran the plain SEV subtest unconditionally, gated only on the X86_FEATURE_SEV CPUID bit, while gating SEV-ES and SNP on the KVM_CAP_VM_TYPES bits. CPUID reporting SEV does not mean KVM offers the SEV VM type: when all SEV ASIDs are assigned to SEV-SNP, KVM_X86_SEV_VM is unavailable even though X86_FEATURE_SEV is set. On such a host the test aborts in KVM_CREATE_VM instead of exercising the available modes. Gate the SEV subtest on KVM_CAP_VM_TYPES like the others, so the test runs the VM types the host actually offers. Reviewed-by: Tycho Andersen (AMD) <tycho@kernel.org> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Message-ID: <2b5e7a83d277134294199a455469bb436196b902.1784545391.git.dwmw@amazon.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: x86/mmu: Fix use-after-free on vendor module reloadPhil Rosenthal
mmu_destroy_caches() destroys pte_list_desc_cache and mmu_page_header_cache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded. If creation of pte_list_desc_cache fails during a subsequent vendor module load, its assignment sets pte_list_desc_cache to NULL and the error path calls mmu_destroy_caches(). mmu_page_header_cache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmem_cache_destroy() causes a slab use-after-free. Reproduce the issue on a v7.1.3 kernel with CONFIG_KASAN=y, CONFIG_KASAN_GENERIC=y, CONFIG_KVM=m, and CONFIG_KVM_INTEL=m. A one-shot test hook forces pte_list_desc_cache to NULL on the second invocation of kvm_mmu_vendor_module_init(): 1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvm_intel, leaving kvm.ko loaded. 3. Reload kvm_intel and force initialization through the -ENOMEM path. KASAN reports: BUG: KASAN: slab-use-after-free in kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... kmem_cache_destroy+0x21/0x1d0 kvm_mmu_vendor_module_init+0x5b/0x170 [kvm] ... Allocated by task 16817: __kmem_cache_create_args+0x12c/0x3b0 __kmem_cache_create.constprop.0+0xb6/0xf0 [kvm] kvm_mmu_vendor_module_init+0x13b/0x170 [kvm] ... Freed by task 16820: kmem_cache_destroy+0x117/0x1d0 kvm_mmu_vendor_module_exit+0x21/0x30 [kvm] Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe. With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report. Fixes: cb498ea2ce1d ("KVM: Portability: Combine kvm_init and kvm_init_x86") Cc: stable@vger.kernel.org Signed-off-by: Phil Rosenthal <phil@phil.gs> Message-ID: <20260718-kvm-mmu-cache-uaf-v3-1-e103b93c74e1@phil.gs> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as rootsHyunwoo Kim
kvm_mmu_zap_oldest_mmu_pages() excludes a shadow page whose root_count is non-zero from top-level reclaim, because such a page cannot be freed. The path in mmu_page_zap_pte() that recursively zaps a parentless nested TDP child has no such check. As a result, a shadow page can be zapped even if the page itself can't be freed; as the comment in kvm_mmu_zap_oldest_mmu_pages() notes, zapping it will just force vCPUs to rebuild the page. As in top-level reclaim, do not recursively prepare zapping of a nested TDP child whose root_count is non-zero. Fixes: 2de4085cccea ("KVM: x86/MMU: Recursively zap nested TDP SPs when zapping last/only parent") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: x86: Check for invalid/obsolete root *after* making MMU pages availableSean Christopherson
Check for a "stale" page fault, i.e. for an invalid and/or obsolete root, after making MMU pages available for the shadow MMU. If reclaiming shadow pages zaps an in-use root, i.e. marks it invalid, then KVM will attempt to map memory into an invalid root. On its own, populating an invalid root is "fine", but because child shadow pages inherit their parent's role, any children created during the map/fetch will be created as invalid pages, thus violating KVM's invariant that invalid pages are never on the list of active MMU pages. Note, the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7, "KVM: MMU: ignore zapped root pagetables"), but the true badness only came along in 2020 (Linux 5.9) with the invariant that invalid shadow pages can't be on the list of active pages. Note #2, inheriting role.invalid when creating child shadow pages is also far from ideal; that flaw will be addressed separately. Reported-by: Hyunwoo Kim <imv4bel@gmail.com> Fixes: f95eec9bed76 ("KVM: x86/mmu: Don't put invalid SPs back on the list of active pages") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21KVM: nVMX: Hide shadow VMCS right after VMCLEARHyunwoo Kim
free_nested() frees the shadow VMCS while vmcs01 still points to it. But because it is asynchronous with respect to loaded_vmcs_clear(), the vCPU might migrate before the pointer is cleared and __loaded_vmcs_clear() may then execute VMCLEAR. The VMCS needs to stay attached until its explicit VMCLEAR completes, but then it can be hidden and the page safely freed. Fixes: 355f4fb1405e ("kvm: nVMX: VMCLEAR an active shadow VMCS after last use") Cc: stable@vger.kernel.org Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2026-07-21net: airoha: Fix DMA direction for NPU mailbox bufferWayen Yan
airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE, but some callers expect the NPU to write response data back into the same buffer: - airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into the buffer, then the caller reads it via memcpy() - airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back npu_stats_addr field in the response On non-cache-coherent architectures like EN7581 (Cortex-A53 without hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op — it does not invalidate the CPU cache. If the NPU-written cache line is still present in the CPU cache when the caller reads the buffer, the CPU observes stale data instead of the NPU response. This is a timing-sensitive bug: small mailbox buffers (~24 bytes) typically fit in a single cache line and may survive in the cache until the caller reads them, producing silent data corruption rather than a crash. The bug is more likely to trigger when the caller reads the response immediately after dma_unmap_single() without intervening cache-evicting operations. Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures dma_unmap_single() invalidates the CPU cache on non-coherent systems. The mailbox buffers are small so there is no performance concern. Fixes: c52918744ee1e49cea86622a2633b9782446428f ("net: airoha: npu: Move memory allocation in airoha_npu_send_msg() caller") Signed-off-by: Wayen Yan <win847@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/178351055214.98729.11403147818632027428@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dpaa2-eth: put MAC endpoint device on disconnectGuangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The Ethernet connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only disconnects and closes the MAC before freeing the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference after closing the MAC and before freeing the dpaa2_mac object. Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20260708111738.750391-1-lgs201920130244@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21KVM: arm64: Update Fuad Tabba's email addressFuad Tabba
Switch my KVM/arm64 reviewer entry to fuad.tabba@linux.dev, my canonical address for kernel work, and add a .mailmap entry so the existing tabba@google.com commits map onto it. Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev> Link: https://patch.msgid.link/20260719163257.3156529-1-fuad.tabba@linux.dev Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-21KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested contextD Scott Phillips
In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts. Fixes: 6dd333c8942b2 ("KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive") Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-arm-kernel/20260710222128.416581-1-scott@os.amperecomputing.com/ Link: https://patch.msgid.link/20260714231158.496808-1-scott@os.amperecomputing.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-21net: airoha: Fix potential use-after-free in airoha_ppe_deinit()Wayen Yan
airoha_ppe_deinit() replaces the NPU pointer with NULL via rcu_replace_pointer() but does not wait for existing RCU readers to exit before calling ppe_deinit() and airoha_npu_put(). This can cause a use-after-free if a reader in an RCU read-side critical section still holds a reference to the NPU when it is freed. The init path (airoha_ppe_init) already calls synchronize_rcu() after rcu_assign_pointer(), but the deinit path introduced in commit 6abcf751bc08 ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()") omitted the matching barrier when switching from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer(). Add synchronize_rcu() before ppe_deinit() to ensure all existing RCU readers have completed before the NPU resources are released. Fixes: 6abcf751bc084804a9e5b3051442e8a2ce67f48a ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()") Signed-off-by: Wayen Yan <win847@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/178351022574.97989.6880403520276841703@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dpaa2-switch: put MAC endpoint device on disconnectGuangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference taken through device_find_child(). The switch port connect path stores that device in mac->mc_dev and keeps it for the lifetime of the connected MAC object. However, the disconnect path only closes the MAC and frees the dpaa2_mac object. It does not drop the endpoint device reference stored in mac->mc_dev, so every successful connect leaks that device reference when the MAC is later disconnected. Drop the endpoint device reference before freeing the dpaa2_mac object. Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260708111025.749311-1-lgs201920130244@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21Merge branch 'vsock-virtio-collapse-receive-queue-under-memory-pressure'Paolo Abeni
Stefano Garzarella says: ==================== vsock/virtio: collapse receive queue under memory pressure This series contains a patch (the first one) that is part of work I'm doing to improve the tracking of memory used by AF_VSOCK sockets. The second patch is a test for our suite that highlights the issue. Since Brien reported an issue with his environment (based on Linux 6.12.y) related to the work I’m doing, I extracted this patch and tried to make it as easy as possible to backport. Brien tested it by backporting it to 6.12.y, which now contains the backport of the 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"). This patch primarily fixes STREAM sockets, but also partially fixes SEQPACKET (with the exception of EOMs, which are kept in separate skbs to avoid overcomplicating the code). The rest of the work, I feel, is more net-next material and still needs some work to be completed. v1: https://lore.kernel.org/netdev/20260626134823.206676-1-sgarzare@redhat.com/ ==================== Link: https://patch.msgid.link/20260708102904.50732-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21vsock/test: add test for small packets under pressureStefano Garzarella
Add a test that sends 2 MB of data using randomly sized small packets (129-512 bytes) over a SOCK_STREAM connection. Packets above GOOD_COPY_LEN (128) bypass the in-place coalescing in recv_enqueue(), forcing each one into its own skb. Without receive queue collapsing, the per-skb overhead eventually exceeds buf_alloc and the connection is reset. The test verifies that all data arrives and that content integrity is preserved. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260708102904.50732-3-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21vsock/virtio: collapse receive queue under memory pressureStefano Garzarella
When many small packets accumulate in the receive queue, the skb overhead can exceed buf_alloc even while the payload is within bounds. This causes virtio_transport_inc_rx_pkt() to reject packets, leading to connection resets during large transfers under backpressure. The issue was reported by Brien, who has a reproducer, but it is also easily reproducible with iperf-vsock [1] using a small packet size: iperf3 --vsock -c $CID -l 129 which fails immediately without this patch but with commit 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue"). Inspired by TCP's tcp_collapse() which solves a similar problem, add virtio_transport_collapse_rx_queue() that walks the receive queue and re-copies data into compact linear skbs to reduce the overhead. The collapse is triggered proactively from when the number of skb queued is close to exceeding the overhead budget. A pre-scan counts the eligible bytes to size each allocation precisely, avoiding waste for isolated small packets. Partially consumed skbs are kept as-is to preserve buf_used/fwd_cnt accounting, EOM-marked skbs to maintain SEQPACKET message boundaries, and skbs already larger than the collapse target because they already have a good data-to-overhead ratio. Walking a large queue may take a significant amount of time and cache misses, causing traffic burstiness. To limit this, the collapse stops once enough room is freed for this packet and the next one, but may opportunistically free more to fill each collapsed skb to capacity. [1] https://github.com/stefano-garzarella/iperf-vsock Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue") Cc: stable@vger.kernel.org Reported-by: Brien Oberstein <brienpub@gmail.com> Closes: https://lore.kernel.org/netdev/618701dd023e$063de350$12b9a9f0$@gmail.com/ Tested-by: Brien Oberstein <brienpub@gmail.com> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Link: https://patch.msgid.link/20260708102904.50732-2-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21platform/x86: asus-nb-wmi: map ProArt key (0x8b) to KEY_PROG3Nizar Al-Kabbani
The dedicated "ProArt" key on the ASUS ProArt PX13 (HN7306) emits ASUS WMI event code 0x8b. This code is absent from the asus-nb-wmi sparse keymap, so pressing the key only produces a "Unknown key code 0x8b" message and does nothing in userspace. On this model the key is exposed solely through the WMI interface and has no HID scancode, so it can only be handled inside asus-nb-wmi. Map 0x8b to KEY_PROG3 so the key emits a bindable event, consistent with the existing KEY_PROG3 mapping used for the ASUS programmable/Armoury key. Signed-off-by: Nizar Al-Kabbani <nizar.m.kabbani@gmail.com> Reviewed-by: Denis Benato <denis.benato@linux.dev> Link: https://patch.msgid.link/20260719090843.66777-1-nizar.m.kabbani@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-21rxrpc: fix io_thread race in rxrpc_wake_up_io_thread()Xuanqiang Luo
rxrpc_wake_up_io_thread() checks local->io_thread before waking it, but then reloads the pointer for wake_up_process(). local->io_thread is cleared with WRITE_ONCE() when the I/O thread exits, so the second load can see NULL even if the first load did not. Take a READ_ONCE() snapshot and use it for both the NULL check and the wake_up_process() call, as rxrpc_encap_rcv() already does. Fixes: 5800b1cf3fd8 ("rxrpc: Allow CHALLENGEs to the passed to the app for a RESPONSE") Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260708093534.53486-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21ntfs: drop stale page-cache when shrinking a non-resident attrNamjae Jeon
ntfs_non_resident_attr_shrink() shrinks attribute sizes but fails to trim the page cache. This leaves orphaned dirty folios beyond the new end of the attribute, leading to writeback failures (-ENOENT), data loss, and $EA chain corruption. Fix this by truncating the page cache to the new size immediately after updating the sizes, preventing writeback from flushing out-of-range folios. Fixes: 495e90fa3348 ("ntfs: update attrib operations") Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-07-21ntfs: harden runlist realloc size calculationsNamjae Jeon
Add a shared helper to safely convert runlist element counts to byte sizes using overflow checks, and use it in both ntfs_rl_realloc() and ntfs_rl_realloc_nofail(). Fixes: 11ccc9107dc4 ("ntfs: update runlist handling and cluster allocator") Co-developed-by: Alper Mudar <kommandant_alper@proton.me> Signed-off-by: Alper Mudar <kommandant_alper@proton.me> Tested-by: Alper Mudar <kommandant_alper@proton.me> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
2026-07-21Merge branch 'ipv4-update-rt_flush_dev-and-two-dst-dev-readers'Paolo Abeni
Xuanqiang Luo says: ==================== ipv4: update rt_flush_dev() and two dst.dev readers From: Xuanqiang Luo <xuanqiang.luo@linux.dev> Patch 1 makes the rt_flush_dev() write to rt->dst.dev use rcu_assign_pointer(), matching the existing dst_dev_rcu() readers. Patch 2 makes ip_rt_send_redirect() and ip_rt_get_source() use one dst.dev snapshot throughout each operation, so a concurrent rt_flush_dev() update cannot make them use values from two devices. v2: https://lore.kernel.org/lkml/20260701032434.17500-1-xuanqiang.luo@linux.dev/ v1: https://lore.kernel.org/all/20260630094250.29386-1-xuanqiang.luo@linux.dev/ ==================== Link: https://patch.msgid.link/20260708060537.17188-1-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()Xuanqiang Luo
rt_flush_dev() can replace rt->dst.dev with blackhole_netdev while RCU readers are running. ip_rt_send_redirect() and ip_rt_get_source() both read rt->dst.dev more than once and use the results in one operation. If rt->dst.dev changes between those reads, the operation can use values from two devices. For example, ip_rt_send_redirect() can use in_dev from the old device and the L3 master ifindex from blackhole_netdev. Read rt->dst.dev once in these two functions and use the snapshot for the later device accesses. Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260708060537.17188-3-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21ipv4: use rcu_assign_pointer() in rt_flush_dev()Xuanqiang Luo
rt_flush_dev() replaces rt->dst.dev with blackhole_netdev on uncached routes. The field is also exposed as dst.dev_rcu, and existing readers use dst_dev_rcu(). Use rcu_assign_pointer() for the replacement, as dst_dev_put() already does for the same field. Signed-off-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260708060537.17188-2-xuanqiang.luo@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21net: skbuff: optimization of net_zcopy_get() call in pskb_carve helpersYun Lu
Commit 98d0912e9f84 ("net: skbuff: fix missing zerocopy reference in pskb_carve helpers") introduced two calls of net_zcopy_get(skb_zcopy(skb)). In fact, skb_zcopy() has already been executed once before. When calling net_zcopy_get(), skb_zcopy() always returns skb_uarg(skb), which results in adding some unnecessary instructions in skb_zcopy. So, change these two calls to directly use skb_uarg(skb) instead of skb_zcopy. In addition, also use net_zcopy_get() instead of refcount_inc() in pskb_expand_head() for code consistency. No functional change intended. Signed-off-by: Yun Lu <luyun@kylinos.cn> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260708055454.9167-1-luyun_611@163.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21slab: silence sparse warning with type-based partitioningMarco Elver
Sparse does not know __builtin_infer_alloc_token() and complains: sparse: sparse: undefined identifier '__builtin_infer_alloc_token' Fix it by using a dummy variant of __kmalloc_token() if __CHECKER__ is defined. Fixes: feb662d9168b ("slab: support for compiler-assisted type-based slab cache partitioning") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607110912.nZTqfCrH-lkp@intel.com/ Signed-off-by: Marco Elver <elver@google.com> Link: https://patch.msgid.link/20260721092005.1986693-1-elver@google.com Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-07-21drm/xe/migrate: Revamp PAT index selection for migrate PTEsSanjay Yadav
Improve PAT index selection logic in xe_migrate.c to avoid unnecessary coherency overhead when host-side memory is uncached. Previously, we defaulted to XE_CACHE_WB, which enforces 2-way coherency and may trigger cacheline pulls from CPU even when host-side memory is never dirty. This change introduces xe_migrate_pat_index() to choose the appropriate PAT index based on the actual TTM caching mode of the buffer object being mapped. For iGPUs with WC host mappings, we now prefer XE_CACHE_NONE to skip coherency snoops. For compressed PTEs on newer platforms, we select XE_CACHE_NONE_COMPRESSION. This avoids unnecessary cache traffic for uncached host mappings. v6: (sashiko) - Only apply the BO's host-side caching for system-memory PTEs. v5: (Matt A) - Simplify emit_pte() to derive caching from res->bo directly, removing the separate bo parameter - Leave changes in __xe_migrate_update_pgtables() and build_pt_update_batch_sram() - Fix comment about page-walker coherency in xe_migrate_pat_index() v4: - Keep xe_migrate_prepare_vm() on XE_CACHE_WB since page tables require page-walker coherency. - Pass BO into emit_pte() and select PAT attributes from the BO's TTM caching mode. Assisted-by: Github-Copilot:claude-opus-4.8 Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav@intel.com> Suggested-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patch.msgid.link/20260710083004.1546599-2-sanjay.kumar.yadav@intel.com
2026-07-21gtp: parse extension headers before reading inner protocolZhixing Chen
GTPv1-U packets may carry a chain of extension headers before the inner IP packet. The receive path already parses and skips these extension headers, but it currently reads the inner protocol before doing so. As a result, the first extension header byte is interpreted as the inner IP version. Packets with extension headers are then dropped before PDP lookup. Parse the extension header chain before calling gtp_inner_proto(), so the inner protocol is read from the actual inner IP header. Fixes: c75fc0b9e5be ("gtp: identify tunnel via GTP device + GTP version + TEID + family") Signed-off-by: Zhixing Chen <running910@gmail.com> Link: https://patch.msgid.link/20260708042244.120898-1-running910@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21rds: drop incoming messages that cross network namespace boundariesAldo Ariel Panzardo
rds_find_bound() looks up the destination socket using a global rhashtable keyed solely on (addr, port, scope_id). Network namespaces are not part of the key, so a sender in netns A can deliver an incoming message (inc) to a socket that lives in a different netns B. When this happens, inc->i_conn points to an rds_connection whose c_net is netns A, but the receiving rs lives in netns B. Once the child process that created netns A exits, cleanup_net() calls rds_loop_exit_net() -> rds_loop_kill_conns() -> rds_conn_destroy(), freeing that connection. If the survivor socket in netns B still holds the inc, any subsequent dereference of inc->i_conn is a use-after-free. There are two dangerous sites in rds_clear_recv_queue(): 1. inc->i_conn->c_lcong (offset 88 of freed rds_connection, size 200) read via rds_recv_rcvbuf_delta() -- confirmed by KASAN. 2. inc->i_conn->c_trans->inc_free(inc) (function pointer at offset 80) called via rds_inc_put() when the inc refcount reaches zero -- same race window, potential call-through-freed-object primitive. The bug is reachable from unprivileged user namespaces (CLONE_NEWUSER + CLONE_NEWNET), available since Linux 3.8. Fix this by rejecting the delivery in rds_recv_incoming() when the socket returned by rds_find_bound() belongs to a different network namespace than the connection that carried the message. Use the existing rds_conn_net() / sock_net() helpers and net_eq() for the comparison. Fixes: c809195f5523 ("rds: clean up loopback rds_connections on netns deletion") Signed-off-by: Aldo Ariel Panzardo <qwe.aldo@gmail.com> Reviewed-by: Allison Henderson <achender@kernel.org> Tested-by: Allison Henderson <achender@kernel.org> Signed-off-by: Allison Henderson <achender@kernel.org> Link: https://patch.msgid.link/20260708024314.601139-1-achender@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21Merge branch 'udp-fix-fou-gue-over-multicast'Paolo Abeni
Anton Danilov says: ==================== udp: fix FOU/GUE over multicast UDP encapsulation (FOU, GUE) has never worked correctly with multicast destination addresses. When a FOU-encapsulated packet arrives at a multicast address, it enters __udp4_lib_mcast_deliver() / __udp6_lib_mcast_deliver() which call consume_skb() on packets that need resubmission to the inner protocol handler, silently dropping them instead. The unicast delivery paths handle this correctly by propagating the return value up to ip[6]_protocol_deliver_rcu() for resubmission, but the multicast paths were never updated to support UDP encapsulation resubmit. This causes silent packet loss for FOU/GRETAP tunnels configured with multicast remote addresses (both IPv4 and IPv6). Reproducing the issue (IPv4): ip netns add ns_a && ip netns add ns_b ip link add veth0 netns ns_a type veth peer name veth1 netns ns_b ip -n ns_a addr add 10.0.0.1/24 dev veth0 && ip -n ns_a link set veth0 up ip -n ns_b addr add 10.0.0.2/24 dev veth1 && ip -n ns_b link set veth1 up ip -n ns_a route add 239.0.0.0/8 dev veth0 ip -n ns_b route add 239.0.0.0/8 dev veth1 # Disable early demux to expose the issue (otherwise it's partially masked) ip netns exec ns_b sysctl -w net.ipv4.ip_early_demux=0 # Join multicast group on receiver ip -n ns_b addr add 239.0.0.1/32 dev veth1 autojoin # Sender: GRETAP with FOU encap ip -n ns_a link add eoudp0 type gretap \ remote 239.0.0.1 local 10.0.0.1 \ encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1 ip -n ns_a link set eoudp0 up ip -n ns_a addr add 192.168.99.1/24 dev eoudp0 # Receiver: FOU listener + GRETAP ip netns exec ns_b ip fou add port 4797 ipproto 47 ip -n ns_b link add eoudp0 type gretap \ remote 239.0.0.1 local 10.0.0.2 \ encap fou encap-sport 4797 encap-dport 4797 key 239.0.0.1 ip -n ns_b link set eoudp0 up ip -n ns_b addr add 192.168.99.2/24 dev eoudp0 # Static neigh: ARP replies can't traverse unidirectional mcast tunnel recv_mac=$(ip -n ns_b link show eoudp0 | awk '/ether/{print $2}') ip -n ns_a neigh add 192.168.99.2 lladdr $recv_mac dev eoudp0 # Test: ping through the FOU/GRETAP tunnel ip netns exec ns_a ping -c 100 192.168.99.2 # -> without this patch: 0 packets received on eoudp0 # -> with this patch: all packets received on eoudp0 IPv6 (using fou6 + ip6gretap) exhibits the same silent drop with a different fix (see 1/2 for the sign-of-ret difference between ip_protocol_deliver_rcu() and ip6_protocol_deliver_rcu()). AI assistance (Claude, claude-opus-4-6) was used during root cause analysis of the kernel source code (tracing the call chain from udp[6]_queue_rcv_skb through encap_rcv to ip[6]_protocol_deliver_rcu, comparing unicast/GSO/multicast paths) and during patch and selftest authoring. v5: https://lore.kernel.org/netdev/cover.1783218197.git.littlesmilingcloud@gmail.com/ v4: https://lore.kernel.org/netdev/cover.1782945956.git.littlesmilingcloud@gmail.com/ v3: https://lore.kernel.org/netdev/cover.1777934869.git.littlesmilingcloud@gmail.com/ v2: https://lore.kernel.org/netdev/ad_dal164gVmImWl@dau-home-pc/ v1 (RFC): https://lore.kernel.org/netdev/ad7MsSJOuUU6EGwS@dau-home-pc/ ==================== Link: https://patch.msgid.link/cover.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21selftests: net: add FOU multicast encapsulation resubmit testAnton Danilov
Add a selftest to verify that FOU-encapsulated packets addressed to a multicast destination are correctly resubmitted to the inner protocol handler (GRE) via the UDP multicast delivery path. Both IPv4 and IPv6 paths are tested. The test creates two network namespaces connected by a veth pair with a FOU/GRETAP (IPv4) and FOU/ip6gretap (IPv6) tunnel using multicast remote addresses (239.0.0.1 and ff0e::1). Ping is sent through each tunnel and received packets are counted on the receiver's tunnel interface. The veth pair is created directly inside the namespaces to avoid possible name collisions with devices in the root namespace. Static neighbor entries are configured on the sender because ARP/ND replies from the receiver cannot traverse the unidirectional multicast tunnel back to the sender. The early demux optimization (net.ipv4.ip_early_demux, which controls both IPv4 and IPv6) is disabled on the receiver to force packets through __udp4_lib_mcast_deliver() / __udp6_lib_mcast_deliver(), which is the code path being tested. Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/a5b65f092d22a12b52fc536c0565b948cd8ecae3.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21udp: fix encapsulation packet resubmit in multicast deliverAnton Danilov
When a UDP encapsulation socket (e.g., FOU) receives a multicast packet, __udp4_lib_mcast_deliver() and __udp6_lib_mcast_deliver() call consume_skb() when udp_queue_rcv_skb() returns a positive value. A positive return value from udp_queue_rcv_skb() indicates that the encap_rcv handler (e.g., fou_udp_recv) has consumed the UDP header and wants the packet to be resubmitted to the IP protocol handler for further processing (e.g., as a GRE packet). The unicast paths handle this correctly by propagating the return value up to ip_protocol_deliver_rcu() / ip6_protocol_deliver_rcu() for resubmission. However, the multicast paths destroy the packet via consume_skb() instead of resubmitting it, causing silent packet loss. This affects any UDP encapsulation (FOU, GUE) combined with multicast destination addresses. Fix this by returning the value from udp_queue_rcv_skb() when it is positive, matching the behavior of the corresponding unicast paths. Note the sign difference between IPv4 and IPv6: - IPv4: udp_unicast_rcv_skb() returns -ret, and ip_protocol_deliver_rcu() resubmits when ret < 0 (using -ret as the protocol number). - IPv6: udp6_unicast_rcv_skb() returns ret, and ip6_protocol_deliver_rcu() resubmits when ret > 0 (using ret as the nexthdr). Both mcast paths now follow the same convention as their respective unicast paths. Suggested-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Anton Danilov <littlesmilingcloud@gmail.com> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/5372ccac062193147e02b991d5328a5c3fa3a85a.1783372173.git.littlesmilingcloud@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21tracing/probes: Fix extra whitespace in trace_probe_kernel.hMasami Hiramatsu (Google)
Clean up extra space after '=' in fetch_store_strlen_user(). Link: https://lore.kernel.org/all/178454430235.296567.9486503882045148585.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21net/mlx5e: Use sender devcom for MPV master-upManjunath Patil
After PCIe DPC recovery, mlx5 reloads the affected functions and replays multiport affiliation events. In the reported failure, the first relevant device error was: pcieport 0000:10:01.1: DPC: containment event pcieport 0000:10:01.1: PCIe Bus Error: severity=Uncorrected (Fatal) pcieport 0000:10:01.1: [ 5] SDES (First) mlx5 recovered the PCI functions and resumed 0000:11:00.1. During that resume, RDMA multiport binding replayed MLX5_DRIVER_EVENT_AFFILIATION_DONE and mlx5e sent MPV_DEVCOM_MASTER_UP. The host then panicked with: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: mlx5_devcom_comp_set_ready+0x5/0x40 [mlx5_core] RDI: 0000000000000000 Call trace included: mlx5_devcom_comp_set_ready mlx5e_devcom_event_mpv mlx5_devcom_send_event mlx5_ib_bind_slave_port mlx5r_mp_probe mlx5_pci_resume MPV devcom registration publishes mlx5e private data to the component peer list before mlx5e_devcom_init_mpv() stores the returned component device in priv->devcom. A concurrent master-up event can therefore reach a peer whose private data is visible but whose priv->devcom backpointer is still NULL. MPV_DEVCOM_MASTER_UP already carries the sender/master mlx5e private data as event_data. The ready bit is stored on the shared devcom component, not on an individual peer. Use the sender devcom when marking the MPV component ready. This preserves the readiness transition while avoiding a NULL dereference of the peer devcom pointer during affiliation replay after PCI error recovery. Fixes: bf11485f8419 ("net/mlx5: Register mlx5e priv to devcom in MPV mode") Assisted-by: Codex:gpt-5 Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com> Cc: stable@vger.kernel.org # 6.7+ Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260707233911.3651139-1-manjunath.b.patil@oracle.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21tracing/kprobe: Remove redundant memset in kprobe_perf_func()Masami Hiramatsu (Google)
kprobe_perf_func() calls memset(&entry[1], 0, dsize) prior to calling store_trace_args(). store_trace_args() populates the entry buffer and handles dynamic data fields. Remove this redundant memset call to align with kretprobe_perf_func() and other probe perf functions. Link: https://lore.kernel.org/all/178454429309.296567.17379087988750549247.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/fprobe: Remove redundant memset in fentry_perf_func()Masami Hiramatsu (Google)
fentry_perf_func() calls memset(&entry[1], 0, dsize) prior to calling store_trace_args(). store_trace_args() populates the entry buffer and handles dynamic data fields. Furthermore, passing dsize (the dynamic data byte length) to memset at &entry[1] (the start of fixed trace arguments) is inaccurate as it zeroes from the fixed args area rather than the dynamic data region. Remove this redundant memset call to align with fexit_perf_func() and other probe perf functions. Link: https://lore.kernel.org/all/178454428366.296567.16465331441301815980.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/fprobe: Remove redundant snprintf in trace_fprobe_match_command_head()Masami Hiramatsu (Google)
trace_fprobe_match_command_head() copies trace_fprobe_symbol(tf) into a local buffer 'buf' of size MAX_COMMON_HEAD_LEN + 1 using snprintf before comparing with argv[0]. Since trace_fprobe_symbol(tf) already returns a null-terminated string, comparing it directly with argv[0] via strcmp() avoids stack buffer usage and potential symbol truncation at MAX_COMMON_HEAD_LEN. Link: https://lore.kernel.org/all/178454427449.296567.12336315661120939938.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Simplify BTF_KIND_PTR case in fetch_type_from_btf_type()Masami Hiramatsu (Google)
Use a ternary operator for checking IS_ENABLED(CONFIG_64BIT) in the BTF_KIND_PTR case of fetch_type_from_btf_type() to simplify the code. Link: https://lore.kernel.org/all/178454426554.296567.17700307233923830044.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Cleanup pointer arithmetic in store_trace_entry_data()Masami Hiramatsu (Google)
In store_trace_entry_data(), edata is cast to unsigned long for pointer offset arithmetic before being cast back to unsigned long *. Cast edata to u8 * instead. Link: https://lore.kernel.org/all/178454425622.296567.16952341966130280432.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Remove unused parameter from parse_probe_var_retval()Masami Hiramatsu (Google)
The parameter 'arg' in parse_probe_var_retval() is unused. Remove it and update its caller accordingly. Link: https://lore.kernel.org/all/178454424711.296567.15352344258939682112.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Remove redundant bounds check in trace_probe_compare_arg_type()Masami Hiramatsu (Google)
In trace_probe_compare_arg_type(), prior to entering the comparison loop, a->nr_args and b->nr_args are checked for equality. Since the loop condition is i < a->nr_args, i is guaranteed to be less than b->nr_args inside the loop. Remove the redundant (b->nr_args <= i) check. Link: https://lore.kernel.org/all/178454423769.296567.6694636865644203423.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Remove redundant boolean conversion in ↵Masami Hiramatsu (Google)
trace_probe_has_single_file() list_is_singular() returns a boolean value, so the double negation (!!) in trace_probe_has_single_file() is redundant. Remove it. Link: https://lore.kernel.org/all/178454422826.296567.4382363406595169533.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21tracing/probes: Remove duplicate MAX_ARRAY_LEN macro definitionMasami Hiramatsu (Google)
MAX_ARRAY_LEN is defined twice in trace_probe.h. Remove the redundant definition. Link: https://lore.kernel.org/all/178454421926.296567.6649983666070787570.stgit@devnote2/ Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2026-07-21Merge branch 'net-add-adin1140-support'Paolo Abeni
Ciprian Regus says: ==================== net: Add ADIN1140 support This series introduces support for the ADIN1140 (also called AD3306) 10BASE-T1S single port MACPHY. The device integrates the MAC and PHY in the same package. The communication with the host CPU is done through an SPI interface, using the Open Alliance TC6 protocol for control and data transactions. As a result, the oa_tc6 framework is used to implement the communication with the device (register accesses and Ethernet frame RX/TX). The MAC and PHY are connected internally using an MII and MDIO bus. The PHY is a half duplex 10Mbps device, which implements both the PLCA RS (IEEE 802.3 clause 148) and CSMA/CD methods of accessing the Ethernet medium. The 10BASE-T1S standard allows multiple PHY devices to be connected (in parallel) on the same single twisted pair network segment, so PLCA can be configured in order to provide a fair access scheme to all the nodes and reduce the jitter introduced by the unordered CSMA/CD transmits. The PHY's internal register map can be accessed using the direct MDIO mode of the OA TC6. The control, status, phy id 1 & 2 C22 registers are mapped to the 0xFF00 - 0xFF03 range. As for C45 addressable devices, the PHY has PCS, PMA and PLCA blocks. The oa_tc6 framework patches are changes that would make the library usable by the subsequent ADIN1140 MAC driver. The protected mode patch is required because the ADIN1140 only allows protected mode OA TC6 control transactions, which the oa_tc6 framework doesn't currently implement. The OA_TC6_BROKEN_PHY quirk patch is required in order to allow the MAC driver to have a custom implementation for the mii_bus access methods as a workaround for hardware issues: 1. The OA TC6 standard defines the direct and indirect access modes for MDIO transactions. The ADIN1140 incorrectly advertises indirect mode only (supported capabilities register - 0x2, bit 9), while actually implementing just the direct mode. We cannot rely on the CAP register to choose an access method (which oa_tc6 does by default, even though it only implements the direct mode), so the driver has to use its own. 2. The ADIN1140 cannot access the C22 register space of the internal PHY, while the PHY is busy receiving frames. If that happens, the CONFIG0 and CONFIG2 registers of the MAC will get corrupted and the data transfer will stop. Those two registers configure settings for the transfer protocol between the MAC and host, so the value for some of their subfields shouldn't be changed while the netdev is up. Since we know the PHY is internal, the MAC driver can implement a custom mii_bus, which can intercept C22 accesses. Most of the registers mapped in the 0x0 - 0x3 range (the only ones the PHY offers) are read only, and their value can be read from somewhere else (e.g the PHYID 1 & 2 have the same value as 0x1 in the MAC memory map). C45 accesses do not cause this issue, so we can properly implement them. Even though they have different driver, the MAC one cannot function without the PHY driver, since the PHY is not compatible with the generic c22 driver. As such CONFIG_ADIN1140 selects CONFIG_ADIN1140_PHY. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> ==================== Link: https://patch.msgid.link/20260708-adin1140-driver-v5-0-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-06 09:45:38 +0000