wireguard-linux/drivers/net/ethernet/intel, branch stable

Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue

2026-10-05T22:44:46Z

Tony Nguyen says: ==================== Fix i40e/ice/iavf VF bonding after netdev lock changes Jose Ignacio Tornos Martinez says: This series fixes VF bonding failures introduced by commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"). When adding VFs to a bond immediately after setting trust mode, MAC address changes fail with -EAGAIN, preventing bonding setup. This affects both i40e (700-series) and ice (800-series) Intel NICs. The core issue is lock contention: iavf_set_mac() is now called with the netdev lock held and waits for MAC change completion while holding it. However, both the watchdog task that sends the request and the adminq_task that processes PF responses also need this lock, creating a deadlock where neither can run, causing timeouts. Additionally, setting VF trust triggers an unnecessary ~10 second VF reset in i40e driver that delays bonding setup, even though filter synchronization happens naturally during normal VF operation. For ice driver, the delay is not so big, but in the same way the operation is not necessary. This series: 1. Eliminates unnecessary VF reset when setting trust in i40e (reset only if revoking trust and VF has advanced features configured). 2. Fixes lock contention by polling admin queue synchronously 3. Eliminates unnecessary VF reset when setting trust in ice, (reset only if revoking trust and VF has advanced features configured). The key fix (patch 2/3) implements a synchronous MAC change operation similar to the approach used for ndo_change_mtu deadlock fix: https://lore.kernel.org/20260211191855.1532226-1-poros@redhat.com Instead of scheduling work and waiting, it: - Sends the virtchnl message directly (not via watchdog) - Polls the admin queue hardware directly for responses - Processes all messages inline (including non-MAC messages) - Returns when complete or times out This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. Testing shows VF bonding now works reliably in ~5 seconds vs 15+ seconds before (i40e), without timeouts or errors (i40e and ice). Tested on Intel 700-series (i40e) and 800-series (ice) dual-port NICs with iavf driver. Thanks to Jan Tluka and Yuying Ma for reporting the issues. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: skip unnecessary VF reset when setting trust iavf: send MAC change request synchronously i40e: skip unnecessary VF reset when setting trust ==================== Link: https://patch.msgid.link/20260928224454.483072-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski

ice: fix metadata_dst refcount handling on representor teardown

2026-10-02T20:41:12Z

ice_eswitch_release_repr() uses metadata_dst_free() to release the representor's metadata_dst. metadata_dst_free() directly frees the underlying memory without checking the dst_entry refcount. When ice_eswitch_port_start_xmit() processes a packet, it takes a reference via dst_hold() and attaches the metadata_dst to the skb. If the representor is torn down while packets are still queued on the lower device (e.g. in a qdisc), the metadata_dst is freed while references are still held. Use dst_release() instead, which correctly decrements the refcount and only frees the object when all references are dropped. The dst subsystem already handles metadata_dst cleanup in dst_destroy() when DST_METADATA is set. Other drivers sharing this pattern (nfp, airoha, bnxt) already use dst_release() for their metadata_dst lifecycle. Fixes: f5396b8a663f7 ("ice: switchdev slow path") Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani Reviewed-by: Simon Horman Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-5-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski

ice: Restore Ordered MMIO Writes for Tx Doorbells

2026-10-02T20:41:05Z

The DQL accounting state which tracks the number of bytes queued for the NIC to transmit, namely dql->num_queued, is updated by the ICE driver when it invokes __netdev_tx_sent_queue(). Subsequently the driver updates the hardware queue tail allowing the NIC to begin processing the work queue. The queue accounting update should be ordered before the NIC begins transmitting descriptors. The transmit path currently updates the hardware doorbell using writel_relaxed(), which (on arm64) does not provide the same ordering guarantees between writes to normal memory and writes to MMIO registers that writel() does. This introduces a potential race where the NIC begins transmitting descriptors before the dql->num_queued update is globally visible. If the NIC finishes before the update is observed by dql_completed(), it detects an invalid state where more bytes have been completed than have been queued. When this happens the following BUG_ON is triggered. BUG_ON(count > num_queued - dql->num_completed); This has been observed and manifests as the following crash (note that the trace has been trimmed) in an environment with sustained network load that uses an Intel Corporation Ethernet Controller E810-XXV for SFP (rev 02) on an arm64 machine. Replacing writel_relaxed() with writel() in a test kernel eliminated the crash in the user's workload, which previously reproduced the issue reliably. kernel BUG at lib/dynamic_queue_limits.c:99 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x268/0x2a0 lr : ice_clean_tx_irq+0x1d4/0x620 [ice] Call trace: dql_completed+0x268/0x2a0 (P) ice_napi_poll+0x94/0x520 [ice] __napi_poll+0x48/0x3f0 net_rx_action+0x194/0x420 This restores the behaviour prior to commit ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support"), which changed the notification mechanism from writel() to writel_relaxed(). Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161572 Fixes: ccde82e90946 ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Bryan Fraschetti Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski

ice: fix use-after-free in dynamic port cleanup

2026-10-02T20:38:08Z

ice_dealloc_dynamic_port() uses dyn_port->vsi->idx to erase the dynamic port from pf->dyn_ports. However, it frees the VSI before reading the index for the erase, resulting in a use-after-free. Follow the reverse of the allocation order in ice_alloc_dynamic_port() by erasing the xarray entry before freeing the VSI. Fixes: eda69d654c7e ("ice: add basic devlink subfunctions support") Cc: stable@vger.kernel.org Signed-off-by: Xuanqiang Luo Reviewed-by: Marcin Szycik Reviewed-by: Aleksandr Loktionov Tested-by: Patryk Holda Signed-off-by: Tony Nguyen Link: https://patch.msgid.link/20260928230429.495442-3-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski

ice: skip unnecessary VF reset when setting trust

2026-09-28T16:09:06Z

Similar to the i40e fix, ice_set_vf_trust() unconditionally calls ice_reset_vf() when the trust setting changes. While the delay is smaller than i40e, this reset is still unnecessary in most cases. When granting trust, no reset is needed - we can just set the capability flag to allow privileged operations. When revoking trust, we only need to reset (conservative approach) if the VF has actually configured advanced features that require cleanup (MAC LLDP filters, promiscuous mode). For VFs in a clean state, we can safely change the trust setting without the disruptive reset. When we do reset, we maintain the original ice pattern that has been reliable in production: cleanup LLDP filters first, then set vf->trusted, then reset. This ensures the privilege capability bit is handled correctly during reset rebuild. When we don't reset, we manually handle the capability flag via helper function, eliminating the delay. Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Aleksandr Loktionov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen

iavf: send MAC change request synchronously

2026-09-28T16:09:06Z

After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations"), iavf_set_mac() is called with the netdev instance lock already held. The function queues a MAC address change request via iavf_replace_primary_mac() and then waits for completion. However, in the current flow, the actual virtchnl message is sent by the watchdog task, which also needs to acquire the netdev lock to run. Additionally, the adminq_task which processes virtchnl responses also needs the netdev lock. This creates a deadlock scenario: 1. iavf_set_mac() holds netdev lock and waits for MAC change 2. Watchdog needs netdev lock to send the request -> blocked 3. Even if request is sent, adminq_task needs netdev lock to process PF response -> blocked 4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -EAGAIN This particularly affects VFs during bonding setup when multiple VFs are enslaved in quick succession. Fix by implementing a synchronous MAC change operation similar to the approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling in callbacks"). The solution: 1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog) 2. Poll the admin queue hardware directly for responses 3. Process all received messages (including non-MAC messages) 4. Return when MAC change completes or times out A new generic function iavf_poll_virtchnl_response() is introduced that can be reused for any future synchronous virtchnl operations. It takes a callback to check completion, allowing flexible condition checking. This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. To support this, change iavf_add_ether_addrs() to return an error code instead of void, allowing callers to detect failures. Additionally, export iavf_mac_add_reject() to enable proper rollback on local failures (timeouts, send errors) - PF rejections are already handled automatically by iavf_virtchnl_completion(). Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on this waitqueue and after the changes it is not needed. Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez Reviewed-by: Przemek Kitszel Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen

i40e: skip unnecessary VF reset when setting trust

2026-09-28T16:09:06Z

The current implementation triggers a VF reset when changing the trust setting, causing a ~10 second delay during bonding setup. In all the cases, the reset causes a ~10 second delay during which: - VF must reinitialize completely - Any in-progress operations (like bonding enslave) fail with timeouts - VF is unavailable When granting trust, no reset is needed - we can just set the capability flag to allow privileged operations. When revoking trust, we only need to reset (conservative approach) if the VF has actually configured advanced features that require cleanup (ADQ/cloud filters, promiscuous mode). For VFs in a clean state, we can safely change the trust setting without the disruptive reset. When we don't reset, we manually handle capability flag via helper function, eliminating the delay. Signed-off-by: Jose Ignacio Tornos Martinez Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen

Merge tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-09-10T21:07:48Z

Pull networking fixes from Jakub Kicinski: "Nothing too exciting, usual stream of fixes. Including fixes from Netfilter, Bluetooth and WPAN. Current release - new code bugs: - Bluetooth: hci_sync: fix not setting CE length properly - eth: enic: match mailbox replies to request numbers Previous releases - regressions: - tunnels: drop stale dst when building an ICMP error for PMTUD - ipv6: null-check fib6_node before accessing in __ip6_del_rt_siblings() (bug in the rtnl_lock -> RCU conversion) - eth: bnxt_en: - fix crashes on Thor2 due to OOB coalescing buffer accesses - prevent queue stop with deferred completions Previous releases - always broken: - eth: - ice: don't dereference pointers from TP_printk() - fix OOB writes on ethtool flow rule dump in 3 drivers - mlx5: fix FEC configuration with RS_544_514_INTERLEAVED_QUAD - dsa: tag_brcm: legacy FCS: request needed tailroom Misc: - net: cap tx_queue_len at S16_MAX to prevent oversized ring alloc - ipv6: flowlabel: cap duplicate leases per socket" * tag 'net-7.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (164 commits) selftests: tc-testing: test action batch failure cleanup net/sched: act_api: release all action references on NEWACTION failure openvswitch: fix wrong flag value in get_ipv6_ext_hdrs() ipmr: account multicast table and route memory net: phy: dp83td510: handle the active-high LED polarity mode net: macb: initialize PTP state before registering clock net: hsr: enable promiscuous mode on interlink port with fwd offload ipv6: fix fib6 walker UAF on seq stop net: stmmac: fix TX descriptor availability check for TSO traffic net/rds: fix tcp stream corruption with large pages net: mana: restore the XDP program pointer when pre-allocation fails net: phy: dp83867: handle the active-high LED polarity mode octeontx2-af: fix PF/CGX debugfs PCI bus lookup net: net_failover: Fix the deadlock in net_failover_slave_name_change() net: phy: mediatek-ge: disable EEE on the MT7530 PHY tcp: reject non zerocopy devmem tx net: ethernet: mtk_eth_soc: populate lpi_interfaces to fix EEE support net: dsa: mt7530: populate lpi_interfaces to fix EEE support net: hinic: fix mailbox segment buffer overflow net: sun4i-emac: fix missing of_node_put() for phy_node ...

eth: ice: don't dereference pointers from TP_printk()

2026-09-08T20:10:35Z

After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead. Fixes: 3089cf6d3caa ("ice: add tracepoints") Signed-off-by: Jakub Kicinski Tested-by: Alexander Nowlin Signed-off-by: Tony Nguyen

ice: add missing xa_destroy for sched_node_ids

2026-09-08T20:10:35Z

Commit 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") added a sched_node_ids xarray to the port info structure, but never called xa_destroy on it. Since xarrays can allocate internal memory, this can result in a memory leak even if every element in the xarray has been removed. The xarray is currently embedded in the port_info structure. This appears to have been done because its use is within functions that take the port_info as a primary argument. However, this complicates managing the lifecycle of the field. The port_info structure is allocated in ice_init_hw() using devm, and it is not released until the devm cleanup when the driver is unloaded. The ice_init_hw() function is called in many places, including devlink reload, and possibly during DDP load after updating the Tx scheduler layout. Adding a call of xa_destroy to the ice_deinit_hw() causes Sashiko to raise multiple concerns due to potential ordering issues and possible ways that port_info could be a dangling reference. To handle this, move the sched_node_ids out of port_info and into the hw structure. All users of the array already have a pointer to hw anyways, and there is only one sched_node_ids per adapter. While here, remove the overly verbose comment explaining the nature of the sched_node_ids xarray. Add the missing xa_destroy to the cleanup path and to ice_deinit_hw(), ensuring that we properly release the xarray memory. This was caught by Sashiko during development of unrelated code. Fixes: 16dfa49406bc ("ice: Introduce new parameters in ice_sched_node") Signed-off-by: Jacob Keller Reviewed-by: Aleksandr Loktionov Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen