kernel/linux.git/drivers/net/ethernet/google, 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

gve: fix header buffer corruption with header-split and HW-GRO

2026-06-19T01:11:02+00:00

The DQO RX datapath programs a per-buffer-queue-descriptor header_buf_addr at post time and reads the split header back at completion time. Both the post and the read currently index the header buffer by queue position rather than by the buffer's identity: - post (gve_rx_post_buffers_dqo): header_buf_addr is computed from bufq->tail - read (gve_rx_dqo): the header is read from desc_idx (the completion queue head index) This relies on the buffer-queue index and the completion-queue index being equal for the start of every packet, i.e. on the device consuming posted buffers and returning completions in the exact same order. That assumption does not hold once HW-GRO is enabled with multiple flows: coalesced segments are accepted and completed in an order that may differ from the order buffers were posted, and segments from different flows may interleave. That results in two problems: 1. Wrong header slot on read. Because the read offset is derived from the completion index (desc_idx) while the device wrote the header to the address programmed for the buffer's buf_id, the driver can copy a header belonging to a different packet. This shows up as throughput drop (about 30% drop and large numbers of TCP retransmissions) with header-split and HW-GRO both enabled and many streams. 2. Header buffer reused while still owned by the device. The driver advances bufq->head by one per completion and re-posts buffers based on that. Arrival of N RX completions only guarantees that at least N RX buffer descriptors have been read by the device. It does not guarantee that the device has relinquished the ownership of all the buffers corresponding to those N descriptors. With out-of-order completions (e.g. the completion for a packet copied into buffer N arrives before the completion for a packet copied into buffer N-1), the driver can re-post and overwrite a header buffer that the device is still going to write into, corrupting the header of a packet whose completion has not yet been processed. Fix both issues by indexing the header buffer by buf_id on both the post and read paths. Reading from buf_id's slot is therefore always correct regardless of completion ordering (fixes problem 1). Indexing by buf_id also ties each header slot to the lifetime of its buffer state. A buffer state is only returned to the free/recycle lists when its own completion (buf_id) is processed, so its header slot can only be re-posted after the device is done with it. This makes header slot reuse safe under out-of-order completions (fixes problem 2). Allocate (gve_rx_alloc_hdr_bufs) and free (gve_rx_free_hdr_bufs) the header buffers based on num_buf_states to match the buf_id indexing. Cc: stable@vger.kernel.org Fixes: 5e37d8254e7f ("gve: Add header split data path") Signed-off-by: Ankit Garg Reviewed-by: Praveen Kaligineedi Reviewed-by: Jordan Rhee Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Reviewed-by: Eric Dumazet Link: https://patch.msgid.link/20260617013208.3781453-1-joshwash@google.com Signed-off-by: Jakub Kicinski

net: ethtool: optionally skip rtnl_lock on Netlink path for SET ops

2026-06-09T17:13:05+00:00

Make ethtool not take rtnl_lock for SET commands when operation is performed on an ops-locked driver. cfg/cfg_pending are now ops-locked, since only ethtool modifies them. Some SET driver callbacks will still need rtnl_lock, most notably those which may end up calling netdev_update_features() or the qdisc layer (via netif_set_real_num_tx_queues()). Let drivers selectively opt back into the rtnl_lock with a new bitfield in ops. We need two helpers since Netlink and ioctl cmds have different values. Keep the helpers side by side in common.h to make sure they get updated together, even tho they will only get called from ioctl.c and netlink.c. SET commands which don't use ethnl_default_set_doit() are converted by subsequent commits. Reviewed-by: Eric Dumazet Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260605002912.3456868-6-kuba@kernel.org Signed-off-by: Jakub Kicinski

net: ethtool: optionally skip rtnl_lock on Netlink path for GET ops

2026-06-09T17:13:04+00:00

ethnl_default_doit() and ethnl_default_dump_one() are both used exclusively for GET callbacks (former to get info for a single device or get global strings). ops-locked devices don't need rtnl_lock for GET callbacks, stop taking it. Introduce an opt-out mechanism for devices which use phylink (fbnic) since phylink currently depends on rtnl_lock protection. Subsequent patches will add more exceptions, anyway. Practically the new helpers for judging if command needs rtnl_lock could also call netdev_need_ops_lock() but I find that it makes the code in the callers slightly less obvious. Add a helper for IOCTLs already, even tho it's unused so that we can keep them in sync as the series progresses. This is the first user-visible step of moving ethtool ops out from under rtnl. Subsequent patches do the same for SET ops, as well as the ioctl path. Reviewed-by: Eric Dumazet Acked-by: Stanislav Fomichev Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260605002912.3456868-5-kuba@kernel.org Signed-off-by: Jakub Kicinski

Revert "Merge branch 'gve-add-support-for-ptp-gettimex64'"

2026-05-20T22:12:16+00:00

This reverts commit 9587ed8137fb83d93f84b858337412f4500b21e9, reversing changes made to bcdfd9fb109e0c9d76c345b2346b6b75ed1f476d. Per tglx's objections: https://lore.kernel.org/87mrxtwzz9.ffs@tglx Signed-off-by: Jakub Kicinski

gve: implement PTP gettimex64

2026-05-20T01:17:28+00:00

Enable chrony and phc2sys to synchronize system clock to NIC clock. Two paths are implemented: a precise path using system counter values sampled by the device, and a fallback path using system counter values sampled in the driver using ptp_read_system_prets()/postts(). To use the precise path, the current system clocksource must match the units returned by the device, which on x86 is X86_TSC and on ARM64 is ARM_ARCH_COUNTER. The clockid requested for the cross-timestamp must be either CLOCK_REALTIME or CLOCK_MONOTONIC_RAW. These conditions hold by default on GCP VMs using Chrony, so we expect the precise path to be used the vast majority of the time. If the system clocksource is changed to kvm-clock, it activates the fallback path. Ethtool counters have been added to count how many times each path is used. The uncertainty window in the precise path is typically around 1-2us, while in the fallback path is around 60-80us. Stub implementions of adjfine and adjtime are added to avoid NULL dereference when phc2sys tries to adjust the clock. Cc: John Stultz Cc: Thomas Gleixner Cc: Stephen Boyd Cc: David Woodhouse Reviewed-by: Jacob Keller Reviewed-by: Willem de Bruijn Reviewed-by: Kevin Yang Reviewed-by: Naman Gulati Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260514225842.110706-4-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: make nic clock reads thread safe

2026-05-20T01:17:27+00:00

Add a mutex to protect the shared DMA buffer that receives NIC timestamp reports. The NIC timestamp will be read from two different threads: the periodic worker and upcoming `gettimex64`. Move clock registration to the last step of initialization to ensure that all data needed by the clock module is initialized before the clock is exposed to usermode. Reviewed-by: Jacob Keller Reviewed-by: Joshua Washington Signed-off-by: Ankit Garg Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260514225842.110706-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: skip error logging for retryable AdminQ commands

2026-05-20T01:17:27+00:00

AdminQ commands may return -EAGAIN under certain transient conditions. These commands are intended to be retried by the driver, so logging a formal error to the system log is misleading and creates unnecessary noise. Modify the logging logic to skip the error message when the result is -EAGAIN, and move logging to dev_err_ratelimited() to avoid spamming the log. Reviewed-by: Jacob Keller Reviewed-by: Joshua Washington Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260514225842.110706-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski

net: convert netmem_tx flag to enum

2026-05-19T01:49:06+00:00

Devices that support netmem TX previously set dev->netmem_tx = true. This was checked in validate_xmit_unreadable_skb() to drop unreadable skbs (skbs with dmabuf-backed frags) before they reach drivers that would mishandle them or devices that would not have the iommu mappings for them. A subsequent patch will introduce a third state for virtual devices that forward unreadable skbs without ever performing DMA on them. To prepare for that, convert the boolean dev->netmem_tx into an enum: NETMEM_TX_NONE - no netmem TX support (drop unreadable skbs) NETMEM_TX_DMA - full support, device does DMA Update the existing NIC drivers (bnxt, gve, mlx5, fbnic) and the validators in net/core to use the new enum. No functional change. Acked-by: Harshitha Ramamurthy Acked-by: Stanislav Fomichev Signed-off-by: Bobby Eshleman Link: https://patch.msgid.link/20260514-tcp-dm-netkit-v5-1-408c59b91e66@meta.com Signed-off-by: Jakub Kicinski

gve: Use generic power management

2026-05-08T22:38:17+00:00

Switch to the generic power management and remove the usage of legacy (pci_driver) hooks. Signed-off-by: Vaibhav Gupta Reviewed-by: Harshitha Ramamurthy Reviewed-by: Alexander Lobakin Link: https://patch.msgid.link/20260506165015.641738-1-vaibhavgupta40@gmail.com Signed-off-by: Jakub Kicinski