From patchwork Mon Aug 24 21:20:13 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rickey Castillo Valenzuela X-Patchwork-Id: 2291404 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4hTP2m6ZbMz1xyZ for ; Tue, 25 Aug 2026 07:20:32 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1wyc5c-0000pL-Pn; Mon, 24 Aug 2026 21:20:20 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1wyc5a-0000ow-T3 for kernel-team@lists.ubuntu.com; Mon, 24 Aug 2026 21:20:18 +0000 Received: from mail-oa1-f72.google.com (mail-oa1-f72.google.com [209.85.160.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id C60BF3F1D3 for ; Mon, 24 Aug 2026 21:20:18 +0000 (UTC) Received: by mail-oa1-f72.google.com with SMTP id 586e51a60fabf-456ab1a7f2cso7336307fac.3 for ; Mon, 24 Aug 2026 14:20:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787606417; x=1788211217; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=0s42qOo+Sg3izTObO5xK5JJv+/DvXPHl+Tl1cdmRScg=; b=Elrfga3wZYin1sijHlTdBQMzJ8ImEx3BS2ZbNcClVj7qJNA2MTuXWd2UTyHRoLnAKn S5rKAvOD52uO50uxYL0MRtAPo5VvkWIYU5hs3C+xumLqDR0N8gkhUdFs1HiKedTCQvUW Pqv4iVl1gGPp9BOrt+u1TjJgvzlBOTZQLoZJvus5fHDPbY7jSWTuKabsmyj3I3WJKjqZ +j2lfaM5yh11r9RnpiIRdC+QsAe614uDM425X1iCG93eYDK99pUbk1lphQupwi7JQ5wJ qvjC8XTdCgGGvkbAdr1fIKOo9SJcfIdtGX6KOrf3aDdinOpSGEDZynBJqWNsPa5GvaS2 CcSw== X-Gm-Message-State: AFuF++kISgVgRjWkY9bZVzckb6wVlHtvV7DvBjNDTkcUXLmjzvFfRCrW 4MWdXv1Cq6GUUSIOWxSyGI7rwEg8i8HBCG1sapUTG/608kjfvFtp/OsZajj86lwaZbkWfbXAEbG REjq5O7xAzQNBFT61UWvx4n2uKYj7AOoBr541pxuQhtMOApEwBMWy5YXmt8DP+/tqRlbJLUlujY +wW9Jus2hlAHuDXP4Zhig= X-Gm-Gg: AR+sD12ap0JO85Ana4q2b/cz8WZAf0P71d8oXAOaD+I0tXQa7WFLkiflJaUeFc8RqMJ rDrojeIc2zSjPNBO1+G9MJM8G/Pf9Kxd+iiptHrzu7f8/IPiUJFwwqXpuzNJlx+LagKyyY3KhXB zRb0aUlUWiOF6mtle5feVzadVlFo5zegHXj+6Z4Dh+ii5YoW2wWOK5Sds22zmgfegNn9bRaLTuh oPkOjZpsNz7GRf6B1qaZKo86Un+H2UPQXkjFBjS0/YMAU9r13dqfPFgHe6EbpEY8ovwUYSz15cN K7+WbuZEd6g+aTn4K+LxZbBWuYt7GT9IDhTR0n+rIhfrxQ0Y3oivxzc7u2rdz93YJI6AYs8pG5I HBVDAs/34FXmfGgVN0VLMMvNoC6Q= X-Received: by 2002:a05:6820:4de8:b0:6ac:c22f:608 with SMTP id 006d021491bc7-6b190444ad0mr1485884eaf.19.1787606417466; Mon, 24 Aug 2026 14:20:17 -0700 (PDT) X-Received: by 2002:a05:6820:4de8:b0:6ac:c22f:608 with SMTP id 006d021491bc7-6b190444ad0mr1485849eaf.19.1787606416979; Mon, 24 Aug 2026 14:20:16 -0700 (PDT) Received: from localhost ([189.163.105.101]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-6b17c8328c2sm4808018eaf.4.2026.08.24.14.20.16 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 14:20:16 -0700 (PDT) To: kernel-team@lists.ubuntu.com Subject: [SRU][J:linux-gcp/N:linux-gcp][PATCH v2 1/2] gve: fix header buffer corruption with header-split and HW-GRO Date: Mon, 24 Aug 2026 15:20:13 -0600 Message-ID: <20260824212014.79217-2-rickey.castillo.valenzuela@canonical.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260824212014.79217-1-rickey.castillo.valenzuela@canonical.com> References: <20260824212014.79217-1-rickey.castillo.valenzuela@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Rickey Castillo via kernel-team From: Rickey Castillo Valenzuela Reply-To: Rickey Castillo Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Ankit Garg BugLink: https://bugs.launchpad.net/bugs/2153950 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 (backported from commit d676c9a73bdcd8237425dbb826f2bd1a25c36e40) [ijwhitfield: Adjusted context due to missing commit: ebdfae0d377b ("gve: adopt page pool for DQ RDA mode") which moved the initialization of desc->buf_id and desc->buf_addr from gve_rx_post_buffers_dqo() to gve_alloc_buffer(), which gets called in the same code path in this kernel.] Signed-off-by: Ian Whitfield Acked-by: Magali Lemes Acked-by: Rickey Castillo Signed-off-by: Ian Whitfield [rickey.castillo: Cherry picked from linux-gke to linux-gcp] Signed-off-by: Rickey Castillo --- drivers/net/ethernet/google/gve/gve_rx_dqo.c | 28 +++++++++++++------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c index 8df733a7e2ef..e593563ef87a 100644 --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c @@ -202,11 +202,13 @@ static int gve_alloc_page_dqo(struct gve_rx_ring *rx, static void gve_rx_free_hdr_bufs(struct gve_priv *priv, struct gve_rx_ring *rx) { struct device *hdev = &priv->pdev->dev; - int buf_count = rx->dqo.bufq.mask + 1; if (rx->dqo.hdr_bufs.data) { - dma_free_coherent(hdev, priv->header_buf_size * buf_count, - rx->dqo.hdr_bufs.data, rx->dqo.hdr_bufs.addr); + size_t size = + (size_t)priv->header_buf_size * rx->dqo.num_buf_states; + + dma_free_coherent(hdev, size, rx->dqo.hdr_bufs.data, + rx->dqo.hdr_bufs.addr); rx->dqo.hdr_bufs.data = NULL; } } @@ -405,7 +407,7 @@ int gve_rx_alloc_ring_dqo(struct gve_priv *priv, /* Allocate header buffers for header-split */ if (cfg->enable_header_split) - if (gve_rx_alloc_hdr_bufs(priv, rx, buffer_queue_slots)) + if (gve_rx_alloc_hdr_bufs(priv, rx, rx->dqo.num_buf_states)) goto err; /* Allocate RX completion queue */ @@ -539,10 +541,13 @@ void gve_rx_post_buffers_dqo(struct gve_rx_ring *rx) desc->buf_id = cpu_to_le16(buf_state - rx->dqo.buf_states); desc->buf_addr = cpu_to_le64(buf_state->addr + buf_state->page_info.page_offset); - if (rx->dqo.hdr_bufs.data) + if (rx->dqo.hdr_bufs.data) { + u16 buf_id = le16_to_cpu(desc->buf_id); + desc->header_buf_addr = cpu_to_le64(rx->dqo.hdr_bufs.addr + - priv->header_buf_size * bufq->tail); + (size_t)priv->header_buf_size * buf_id); + } bufq->tail = (bufq->tail + 1) & bufq->mask; complq->num_free_slots--; @@ -789,10 +794,13 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx, int unsplit = 0; if (hdr_len && !hbo) { - rx->ctx.skb_head = gve_rx_copy_data(priv->dev, napi, - rx->dqo.hdr_bufs.data + - desc_idx * priv->header_buf_size, - hdr_len); + size_t offset = + (size_t)buffer_id * priv->header_buf_size; + + rx->ctx.skb_head = + gve_rx_copy_data(priv->dev, napi, + rx->dqo.hdr_bufs.data + offset, + hdr_len); if (unlikely(!rx->ctx.skb_head)) goto error; rx->ctx.skb_tail = rx->ctx.skb_head; From patchwork Mon Aug 24 21:20:14 2026 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rickey Castillo Valenzuela X-Patchwork-Id: 2291402 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ubuntu.com (client-ip=185.125.189.65; helo=lists.ubuntu.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=patchwork.ozlabs.org) Received: from lists.ubuntu.com (lists.ubuntu.com [185.125.189.65]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4hTP2m5zwZz1xwD for ; Tue, 25 Aug 2026 07:20:32 +1000 (AEST) Received: from localhost ([127.0.0.1] helo=lists.ubuntu.com) by lists.ubuntu.com with esmtp (Exim 4.86_2) (envelope-from ) id 1wyc5d-0000pc-0Y; Mon, 24 Aug 2026 21:20:21 +0000 Received: from smtp-relay-internal-0.internal ([10.131.114.225] helo=smtp-relay-internal-0.canonical.com) by lists.ubuntu.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1wyc5b-0000pC-Vb for kernel-team@lists.ubuntu.com; Mon, 24 Aug 2026 21:20:20 +0000 Received: from mail-oi1-f199.google.com (mail-oi1-f199.google.com [209.85.167.199]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id C43183F1D3 for ; Mon, 24 Aug 2026 21:20:19 +0000 (UTC) Received: by mail-oi1-f199.google.com with SMTP id 5614622812f47-4b2f2b8d88fso7788433b6e.2 for ; Mon, 24 Aug 2026 14:20:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787606418; x=1788211218; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=vkh93OHxFEcgPAqLqIKinVgscoyl9lLiGB+j8hMymek=; b=C4/+MDqO4e3Bjmfh4A+UJOAikVrY5Ng4ysXCLQ4oIwq773oCFj+vTHHuCs90Vdn/bw R33LTQSXnILw/3k6w3BGLzdt8YQ3KWs3VgWqYOiou/aAmak9vQPiH/Rl/RQV8367xfjB /M61USgrOz6GWibupHgstE9AaDkewJRCmPwN+vsy5nv3OtABtUVOtzy87t8PAJP+SzSZ mXcL04NA3PypOOSNfaI6U1Te817nprqB1PodI7UXdsvrwCvv6Cib70x2GdazHNAdUYA1 28QW8xqLTz0ECYsEg8KMxXg9pCTEWSyqShs1YpzcdNExDj7s2744Pl6LH4Ye7q+isclb wBfw== X-Gm-Message-State: AFuF++lXNJusMGOOzRBb6JoXIYljEQq1DDqN+UuPxDKkSnmnvEqXzkr7 pnOMi1HX6yhsGbz5XyyECssS5FMwEF/Vcp+pYBX2Zh8g4zF7qqgBvrBucHiYSen8hrvL+/EayUB yuRF9oCks40Nu0d2JRdqAgeMZLuDKk5gqGAzBLFKRZUMeUPhXMtOD7L+Vfut0Z34tycLmhVkz7i rs12/ypPU5AwepigeciLs= X-Gm-Gg: AR+sD13xXWYPxu0aEZewh4xjtBYZBQvOEcrhTxFlpPQim20zGQpJjWCTMnbmtY3a/lo t4el76AbnO1ReYtU4yFXdVocE5+6HGR6/uUvoJP+lp59DQgA1FMGv7WyDzGQZcxz5aMx27ivdpW zVE0BH4tFRE6LYtAMCBHuaMhAB8egjMUgf1OH6FzmFFf+L1M6PsNxQVIo+ISbHBuTDzzVevxbMK suaVHa5lUYGt7Teyd2H0/IBMwqJu84FocicTwmZ46KOu7WYKyvWsbYLKoXRm52vSZhW8FI5Fc5n bQC0L4Rn3LG5GPiAtmq3e6XrwlfFxgqkR2aOek6Nf2yIFkvvNQbGJ5hdpw3Ki8JULOur4xa324h pvJSzFgjSdWlqildZmUTlgfKiWjk= X-Received: by 2002:a05:6808:13c2:b0:4b2:6ca6:9cd8 with SMTP id 5614622812f47-4b2ef25db7bmr32030010b6e.1.1787606418541; Mon, 24 Aug 2026 14:20:18 -0700 (PDT) X-Received: by 2002:a05:6808:13c2:b0:4b2:6ca6:9cd8 with SMTP id 5614622812f47-4b2ef25db7bmr32029960b6e.1.1787606418092; Mon, 24 Aug 2026 14:20:18 -0700 (PDT) Received: from localhost ([189.163.105.101]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-463835a6b93sm6312873fac.17.2026.08.24.14.20.17 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 14:20:17 -0700 (PDT) To: kernel-team@lists.ubuntu.com Subject: [SRU][J:linux-gcp/N:linux-gcp][PATCH v2 2/2] gve: fix zero-length skb frag with header-split Date: Mon, 24 Aug 2026 15:20:14 -0600 Message-ID: <20260824212014.79217-3-rickey.castillo.valenzuela@canonical.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260824212014.79217-1-rickey.castillo.valenzuela@canonical.com> References: <20260824212014.79217-1-rickey.castillo.valenzuela@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Rickey Castillo via kernel-team From: Rickey Castillo Valenzuela Reply-To: Rickey Castillo Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Jordan Rhee BugLink: https://bugs.launchpad.net/bugs/2153950 When header split is enabled and a header-only packet is received such as a pure TCP ACK, GVE will indicate an RX SKB with a zero-length fragment. If this SKB is then hairpinned and sent back out, the GVE TX path will emit a zero-length descriptor. Hardware considers this an illegal descriptor and stops the queue, causing a TX timeout and interface reset. Fix it by not adding the zero-length skb frag. Cc: stable@vger.kernel.org Fixes: 5e37d8254e7f ("gve: Add header split data path") Suggested-by: Praveen Kaligineedi Co-developed-by: Ziwei Xiao Signed-off-by: Ziwei Xiao Signed-off-by: Jordan Rhee Signed-off-by: Harshitha Ramamurthy Link: https://patch.msgid.link/20260807224315.234152-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski (backported from commit 6bf14575c65569dcded90ef78afb8a6d57323f04) [ijwhitfield: Adjusted context due to missing commit: 62d7f40503bc6 ("gve: support unreadable netmem") Also changed gve_buffer_free to a call to gve_enqueue_buf_state to add the buffer to a list of recycled buffers, essentially. This change was needed because this kernel is missing: ebdfae0d377b4 ("gve: adopt page pool for DQ RDA mode") which adds gve_buffer_free in order to handle buffer freeing differently when using new page pool behavior. Since we don't have that commit which adds the page pool behavior, we can free the buffer the old way as was done before the patch.] Signed-off-by: Ian Whitfield Acked-by: Magali Lemes Acked-by: Rickey Castillo Signed-off-by: Ian Whitfield [rickey.castillo: Cherry picked from linux-gke to linux-gcp] Signed-off-by: Rickey Castillo --- drivers/net/ethernet/google/gve/gve_rx_dqo.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/google/gve/gve_rx_dqo.c b/drivers/net/ethernet/google/gve/gve_rx_dqo.c index e593563ef87a..8de1b97209e9 100644 --- a/drivers/net/ethernet/google/gve/gve_rx_dqo.c +++ b/drivers/net/ethernet/google/gve/gve_rx_dqo.c @@ -812,6 +812,11 @@ static int gve_rx_dqo(struct napi_struct *napi, struct gve_rx_ring *rx, rx->rx_hsplit_unsplit_pkt += unsplit; rx->rx_hsplit_bytes += hdr_len; u64_stats_update_end(&rx->statss); + + if (!buf_len) { + gve_enqueue_buf_state(rx, &rx->dqo.recycled_buf_states, buf_state); + return 0; + } } /* Sync the portion of dma buffer for CPU to read. */