kernel/linux.git/drivers/net/ethernet/microsoft, branch v7.2-rc1

net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()

2026-06-25T17:18:34+00:00

Breno reports following splats on mlx5: RTNL: assertion failed at net/core/dev.c (2241) WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335 RIP: 0010:netif_state_change+0xf9/0x130 Call Trace: __linkwatch_sync_dev+0xea/0x120 ethtool_op_get_link+0xe/0x20 __ethtool_get_link+0x26/0x40 linkstate_prepare_data+0x51/0x200 ethnl_default_doit+0x213/0x470 genl_family_rcv_msg_doit+0xdd/0x110 Looks like I missed ethtool_op_get_link() trying to sync linkwatch, which needs rtnl_lock. Not all drivers do this - bnxt doesn't, it just returns the link state, so add an opt-in bit. Reported-by: Breno Leitao Fixes: 45079e00133e ("net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops") Acked-by: Stanislav Fomichev Reviewed-by: Breno Leitao Acked-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260624190439.2521219-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: mana: Optimize irq affinity for low vcpu configs

2026-06-25T16:10:35+00:00

Before the commit 755391121038 ("net: mana: Allocate MSI-X vectors dynamically"), all the MANA IRQs were assigned statically and together during early driver load. After this commit, the IRQ allocation for MANA was done in two phases. HWC IRQ allocated earlier and then, queue IRQs dynamically added at a later point. By this time, the IRQ weights on vCPUs can become imbalanced and if IRQ count is greater than the vCPU count the topology aware IRQ distribution logic in MANA can cause multiple MANA IRQs to land on the same vCPUs, while other sibling vCPUs have none (case 1). On SMP enabled, low-vCPU systems, this becomes a bigger problem as the softIRQ handling overhead of two IRQs on the same vCPUs becomes much more than their overheads if they were spread across sibling vCPUs. In such cases when many parallel TCP connections are tested, the throughput drops significantly. Fix the affinity assignment logic, in cases where the IRQ count is greater than the vCPU count and when IRQs are added dynamically, by utilizing all the vCPUs irrespective of their NUMA/core bindings (case 2). The results of setting the affinity and hint to NULL were also studied, and we observed that, with this logic if there are pre-existing IRQs allocated on the VM (apart from MANA), during MANA IRQs allocation, it leads to clustering of the MANA queue IRQs again (case 3). ======================================================= Case 1: without this patch ======================================================= 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 0 IRQ2: mana_q2 2 IRQ3: mana_q3 0 IRQ4: mana_q4 3 %soft on each vCPU(mpstat -P ALL 1) on receiver vCPU 0 1 2 3 ======================================================= pass 1: 38.85 0.03 24.89 24.65 pass 2: 39.15 0.03 24.57 25.28 pass 3: 40.36 0.03 23.20 23.17 ======================================================= Case 2: with this patch ======================================================= 4 vcpu(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 0 IRQ2: mana_q2 1 IRQ3: mana_q3 2 IRQ4: mana_q4 3 %soft on each vCPU(mpstat -P ALL 1) on receiver vCPU 0 1 2 3 ======================================================= pass 1: 15.42 15.85 14.99 14.51 pass 2: 15.53 15.94 15.81 15.93 pass 3: 16.41 16.35 16.40 16.36 ======================================================= Case 3: with affinity set to NULL ======================================================= 4 vCPU(2 cores), 5 MANA IRQs (1 HWC + 4 Queue) TYPE effective vCPU aff ======================================================= IRQ0: HWC 0 IRQ1: mana_q1 2 IRQ2: mana_q2 3 IRQ3: mana_q3 2 IRQ4: mana_q4 3 ======================================================= Throughput Impact(in Gbps, same env) ======================================================= TCP conn with patch w/o patch aff NULL 20480 15.65 7.73 5.25 10240 15.63 8.93 5.77 8192 15.64 9.69 7.16 6144 15.64 13.16 9.33 4096 15.69 15.75 13.50 2048 15.69 15.83 13.61 1024 15.71 15.28 13.60 Fixes: 755391121038 ("net: mana: Allocate MSI-X vectors dynamically") Cc: stable@vger.kernel.org Co-developed-by: Erni Sri Satya Vennela Signed-off-by: Erni Sri Satya Vennela Signed-off-by: Shradha Gupta Reviewed-by: Haiyang Zhang Reviewed-by: Simon Horman Reviewed-by: Yury Norov Link: https://patch.msgid.link/20260624072138.1632849-1-shradhagupta@linux.microsoft.com Signed-off-by: Jakub Kicinski

net: mana: Fall back to standard MTU when PF reports adapter_mtu of 0

2026-06-25T00:56:44+00:00

Commit d7709812e13d ("net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG") rejected any adapter_mtu value smaller than ETH_MIN_MTU + ETH_HLEN, including 0, returning -EPROTO and failing mana_probe(). Some older PF firmware versions still in the field report adapter_mtu as 0 in the MANA_QUERY_DEV_CONFIG response. With the hardening check in place, the MANA VF driver now fails to load on those hosts, breaking networking entirely for guests. MANA hardware always supports the standard Ethernet MTU. Treat a reported adapter_mtu of 0 as "the PF did not advertise a value" and fall back to ETH_FRAME_LEN, the same value used for the pre-V2 message version path. Only jumbo frames remain unavailable until the PF reports a valid MTU. Other small-but-nonzero bogus values are still rejected, preserving the original protection against the unsigned-subtraction wrap that would otherwise let ndev->max_mtu underflow to a huge value. Fixes: d7709812e13d ("net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG") Signed-off-by: Erni Sri Satya Vennela Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260619055348.467224-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-06-16T21:59:58+00:00

Merge in late fixes in preparation for the net-next PR. Conflicts: net/tls/tls_sw.c 406e8a651a7b ("net: skmsg: preserve sg.copy across SG transforms") 79511603a65b ("tls: remove dead sockmap (psock) handling from the SW path") drivers/net/ethernet/microsoft/mana/mana_en.c f8fd56977eeea ("net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check") d07efe5a6e641 ("net: mana: Use per-queue allocation for tx_qp to reduce allocation size") https://lore.kernel.org/ajAPXu-C_PuTgV-a@sirena.org.uk No adjacent changes. Signed-off-by: Jakub Kicinski

net: mana: guard TX wq object destroy with INVALID_MANA_HANDLE check

2026-06-13T00:26:05+00:00

mana_create_txq() has several error paths (after mana_alloc_queues() or mana_create_wq_obj() failure) where tx_qp[i].tx_object stays as the INVALID_MANA_HANDLE sentinel set at allocation. mana_destroy_txq() then unconditionally calls mana_destroy_wq_obj() with (u64)-1, which firmware rejects and logs an error. Mirror the RX-side pattern in mana_destroy_rxq() and skip the destroy when the handle is still INVALID_MANA_HANDLE. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Dipayaan Roy Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260608101345.2267320-3-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski

net: mana: initialize gdma queue id to INVALID_QUEUE_ID

2026-06-13T00:26:05+00:00

mana_gd_create_mana_wq_cq() leaves queue->id as 0 (from kzalloc_obj()) until mana_create_wq_obj() assigns the firmware-returned id. If creation fails before that, cleanup calls mana_gd_destroy_cq() with id 0, NULLing gc->cq_table[0] and silently breaking whichever real CQ owns that slot. Initialize queue->id to INVALID_QUEUE_ID right after allocation, matching mana_gd_create_eq(). The existing (id >= max_num_cqs) guard then short-circuits cleanly. Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") Signed-off-by: Aditya Garg Reviewed-by: Dipayaan Roy Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/20260608101345.2267320-2-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski

net: mana: Cache MANA_QUERY_LINK_CONFIG result to avoid repeated HWC queries

2026-06-10T00:56:21+00:00

mana_query_link_cfg() sends an HWC command to firmware on every call, but the link speed and QoS values it returns only change when the driver explicitly calls mana_set_bw_clamp(). This function is called not only by userspace via ethtool get_link_ksettings, but also periodically by hv_netvsc through netvsc_get_link_ksettings and by the sysfs speed_show attribute via dev_attr_show, resulting in unnecessary HWC traffic every few minutes. Add a link_cfg_error field to mana_port_context to cache the query result. The field uses three states: 1 (not yet queried, initial value set during mana_probe_port), 0 (success, speed/max_speed are valid), or a negative errno for permanent errors like -EOPNOTSUPP when the hardware does not support the command. Transient errors and qos_unconfigured responses are not cached so that subsequent calls will retry. MANA is ops-locked because it implements net_shaper_ops, so the core already takes netdev_lock() around all ethtool_ops and net_shaper_ops entry points. Reuse that lock to serialize mana_query_link_cfg() and mana_set_bw_clamp(). This prevents a concurrent mana_set_bw_clamp() from racing with an in-flight query and publishing stale pre-clamp speed/max_speed. Invalidate the cache inside mana_set_bw_clamp() on success, so all current and future callers that change the link configuration automatically trigger a fresh query on the next mana_query_link_cfg() call. Also reset link_cfg_error during resume in mana_probe() under netdev_lock(), so that any query already in flight cannot later store 0 and silently overwrite the post-resume invalidation. Signed-off-by: Erni Sri Satya Vennela Link: https://patch.msgid.link/20260606133301.2180073-1-ernis@linux.microsoft.com Signed-off-by: Jakub Kicinski

net: mana: Add support for PF device 0x00C1

2026-06-10T00:51:55+00:00

Update the device id table to include the new device id 0x00C1. This device's BAR layout is similar to VF's, update the function, mana_gd_init_registers(), accordingly. Signed-off-by: Haiyang Zhang Link: https://patch.msgid.link/20260605212302.2135499-1-haiyangz@linux.microsoft.com Signed-off-by: Jakub Kicinski

net: mana: Allocate interrupt context for each EQ when creating vPort

2026-06-10T00:22:27+00:00

Use GIC functions to create a dedicated interrupt context or acquire a shared interrupt context for each EQ when setting up a vPort. The caller now owns the GIC reference across the EQ create/destroy lifecycle: mana_create_eq() calls mana_gd_get_gic() before creating each EQ and mana_destroy_eq() calls mana_gd_put_gic() after destroying it. The msix_index invalidation is moved from mana_gd_deregister_irq() to the mana_gd_create_eq() error path so that mana_destroy_eq() can read the index before teardown. Signed-off-by: Long Li Link: https://patch.msgid.link/20260605005717.2059954-6-longli@microsoft.com Signed-off-by: Jakub Kicinski

net: mana: Use GIC functions to allocate global EQs

2026-06-10T00:22:27+00:00

Replace the GDMA global interrupt setup code with the new GIC allocation and release functions for managing interrupt contexts. This changes the per-queue interrupt names in /proc/interrupts from mana_q0, mana_q1, ... to mana_msi1, mana_msi2, ... to reflect the MSI-X index rather than a zero-based queue number. The HWC interrupt name (mana_hwc) is unchanged. Signed-off-by: Long Li Link: https://patch.msgid.link/20260605005717.2059954-5-longli@microsoft.com Signed-off-by: Jakub Kicinski