kernel/linux.git/drivers/net/ethernet/google, branch v6.19.11

gve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL

2026-03-12T11:09:34+00:00

commit fb868db5f4bccd7a78219313ab2917429f715cea upstream. In DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA buffer cleanup path. It iterates num_bufs times and attempts to unmap entries in the dma array. This leads to two issues: 1. The dma array shares storage with tx_qpl_buf_ids (union). Interpreting buffer IDs as DMA addresses results in attempting to unmap incorrect memory locations. 2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed the size of the dma array, causing out-of-bounds access warnings (trace below is how we noticed this issue). UBSAN: array-index-out-of-bounds in drivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of range for type 'dma_addr_t[18]' (aka 'unsigned long long[18]') Workqueue: gve gve_service_task [gve] Call Trace: dump_stack_lvl+0x33/0xa0 __ubsan_handle_out_of_bounds+0xdc/0x110 gve_tx_stop_ring_dqo+0x182/0x200 [gve] gve_close+0x1be/0x450 [gve] gve_reset+0x99/0x120 [gve] gve_service_task+0x61/0x100 [gve] process_scheduled_works+0x1e9/0x380 Fix this by properly checking for QPL mode and delegating to gve_free_tx_qpl_bufs() to reclaim the buffers. Cc: stable@vger.kernel.org Fixes: a6fb8d5a8b69 ("gve: Tx path for DQO-QPL") Signed-off-by: Ankit Garg Reviewed-by: Jordan Rhee Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Reviewed-by: Simon Horman Link: https://patch.msgid.link/20260220215324.1631350-1-joshwash@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

gve: Correct ethtool rx_dropped calculation

2026-02-04T03:28:05+00:00

The gve driver's "rx_dropped" statistic, exposed via `ethtool -S`, incorrectly includes `rx_buf_alloc_fail` counts. These failures represent an inability to allocate receive buffers, not true packet drops where a received packet is discarded. This misrepresentation can lead to inaccurate diagnostics. This patch rectifies the ethtool "rx_dropped" calculation. It removes `rx_buf_alloc_fail` from the total and adds `xdp_tx_errors` and `xdp_redirect_errors`, which represent legitimate packet drops within the XDP path. Cc: stable@vger.kernel.org Fixes: 433e274b8f7b ("gve: Add stats for gve.") Signed-off-by: Max Yuan Reviewed-by: Jordan Rhee Reviewed-by: Joshua Washington Reviewed-by: Matt Olson Signed-off-by: Harshitha Ramamurthy Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260202193925.3106272-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: Fix stats report corruption on queue count change

2026-02-04T03:28:05+00:00

The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats. When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting. This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC. Cc: stable@vger.kernel.org Fixes: 24aeb56f2d38 ("gve: Add Gvnic stats AQ command and ethtool show/set-priv-flags.") Signed-off-by: Debarghya Kundu Reviewed-by: Joshua Washington Signed-off-by: Harshitha Ramamurthy Reviewed-by: Jacob Keller Link: https://patch.msgid.link/20260202193925.3106272-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: fix probe failure if clock read fails

2026-01-28T02:33:27+00:00

If timestamping is supported, GVE reads the clock during probe, which can fail for various reasons. Previously, this failure would abort the driver probe, rendering the device unusable. This behavior has been observed on production GCP VMs, causing driver initialization to fail completely. This patch allows the driver to degrade gracefully. If gve_init_clock() fails, it logs a warning and continues loading the driver without PTP support. Cc: stable@vger.kernel.org Fixes: a479a27f4da4 ("gve: Move gve_init_clock to after AQ CONFIGURE_DEVICE_RESOURCES call") Signed-off-by: Jordan Rhee Reviewed-by: Shachar Raindel Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260127010210.969823-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: defer interrupt enabling until NAPI registration

2025-12-29T18:09:49+00:00

Currently, interrupts are automatically enabled immediately upon request. This allows interrupt to fire before the associated NAPI context is fully initialized and cause failures like below: [ 0.946369] Call Trace: [ 0.946369] [ 0.946369] __napi_poll+0x2a/0x1e0 [ 0.946369] net_rx_action+0x2f9/0x3f0 [ 0.946369] handle_softirqs+0xd6/0x2c0 [ 0.946369] ? handle_edge_irq+0xc1/0x1b0 [ 0.946369] __irq_exit_rcu+0xc3/0xe0 [ 0.946369] common_interrupt+0x81/0xa0 [ 0.946369] [ 0.946369] [ 0.946369] asm_common_interrupt+0x22/0x40 [ 0.946369] RIP: 0010:pv_native_safe_halt+0xb/0x10 Use the `IRQF_NO_AUTOEN` flag when requesting interrupts to prevent auto enablement and explicitly enable the interrupt in NAPI initialization path (and disable it during NAPI teardown). This ensures that interrupt lifecycle is strictly coupled with readiness of NAPI context. Cc: stable@vger.kernel.org Fixes: 1dfc2e46117e ("gve: Refactor napi add and remove functions") Signed-off-by: Ankit Garg Reviewed-by: Jordan Rhee Reviewed-by: Joshua Washington Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20251219102945.2193617-1-hramamurthy@google.com Signed-off-by: Paolo Abeni

gve: Move gve_init_clock to after AQ CONFIGURE_DEVICE_RESOURCES call

2025-12-05T01:54:16+00:00

commit 46e7860ef941 ("gve: Move ptp_schedule_worker to gve_init_clock") moved the first invocation of the AQ command REPORT_NIC_TIMESTAMP to gve_probe(). However, gve_init_clock() invoking REPORT_NIC_TIMESTAMP is not valid until after gve_probe() invokes the AQ command CONFIGURE_DEVICE_RESOURCES. Failure to do so results in the following error: gve 0000:00:07.0: failed to read NIC clock -11 This was missed earlier because the driver under test was loaded at runtime instead of boot-time. The boot-time driver had already initialized the device, causing the runtime driver to successfully call gve_init_clock() incorrectly. Fixes: 46e7860ef941 ("gve: Move ptp_schedule_worker to gve_init_clock") Reviewed-by: Ankit Garg Signed-off-by: Tim Hostetler Signed-off-by: Harshitha Ramamurthy Reviewed-by: Simon Horman Link: https://patch.msgid.link/20251202200207.1434749-1-hramamurthy@google.com Signed-off-by: Jakub Kicinski

gve: Fix race condition on tx->dropped_pkt update

2025-11-28T01:44:52+00:00

The tx->dropped_pkt counter is a 64-bit integer that is incremented directly. On 32-bit architectures, this operation is not atomic and can lead to read/write tearing if a reader accesses the counter during the update. This can result in incorrect values being reported for dropped packets. To prevent this potential data corruption, wrap the increment operation with u64_stats_update_begin() and u64_stats_update_end(). This ensures that updates to the 64-bit counter are atomic, even on 32-bit systems, by using a sequence lock. The u64_stats_sync API requires the writer to have exclusive access, which is already provided in this context by the network stack's serialization of the transmit path (net_device_ops::ndo_start_xmit [1]) for a given queue. [1]: https://www.kernel.org/doc/Documentation/networking/netdevices.txt Signed-off-by: Max Yuan Reviewed-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Signed-off-by: Jakub Kicinski

gve: Add Rx HWTS metadata to AF_XDP ZC mode

2025-11-18T14:52:43+00:00

By overlaying the struct gve_xdp_buff on top of the struct xdp_buff_xsk that AF_XDP utilizes, the driver records the 32 bit timestamp via the completion descriptor and the cached 64 bit NIC timestamp via gve_priv. The driver's implementation of xmo_rx_timestamp extends the timestamp to the full and up to date 64 bit timestamp and returns it to the user. gve_rx_xsk_dqo is modified to accept a pointer to the completion descriptor and no longer takes a buf_len explicitly as it can be pulled out of the descriptor. With this patch gve now supports bpf_xdp_metadata_rx_timestamp. Signed-off-by: Tim Hostetler Reviewed-by: Willem de Bruijn Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20251114211146.292068-5-joshwash@google.com Signed-off-by: Paolo Abeni

gve: Prepare bpf_xdp_metadata_rx_timestamp support

2025-11-18T14:52:43+00:00

Support populating XDP RX metadata with hardware RX timestamps. This patch utilizes the same underlying logic to calculate hardware timestamps as the regular RX path. xdp_metadata_ops is registered with the net_device in a future patch. gve_rx_calculate_hwtstamp was pulled out so as to not duplicate logic between gve_xdp_rx_timestamp and gve_rx_hwtstamp. Signed-off-by: Tim Hostetler Reviewed-by: Willem de Bruijn Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20251114211146.292068-4-joshwash@google.com Signed-off-by: Paolo Abeni

gve: Wrap struct xdp_buff

2025-11-18T14:52:42+00:00

RX timestamping will need to keep track of extra temporary information per-packet. In preparation for this, introduce gve_xdp_buff to wrap the xdp_buff. This is similar in function to stmmac_xdp_buff and ice_xdp_buff. Signed-off-by: Tim Hostetler Reviewed-by: Willem de Bruijn Reviewed-by: Harshitha Ramamurthy Signed-off-by: Joshua Washington Link: https://patch.msgid.link/20251114211146.292068-3-joshwash@google.com Signed-off-by: Paolo Abeni