linux-toradex.git/drivers/net/ethernet/google, branch master Linux kernel for Apalis and Colibri modules gve: DQO: accept TSO packets with non-protocol gso_type bits 2026-09-29T10:09:40+00:00 Hannu Varjoranta hannu@varjosoft.com 2026-09-25T11:52:37+00:00 f8932b2c0c9ae6fb577bcc05a2080c8498f91c0d Since commit 014c607f86ab ("gve: add support for UDP GSO for DQO format"), gve_prep_tso() matches shinfo->gso_type exactly. gso_type is a bitmask, though: SKB_GSO_DODGY is set on every GSO packet that comes from tun/tap, packet sockets or other untrusted sources, and SKB_GSO_TCP_ECN and SKB_GSO_TCP_FIXEDID can be set as well. Such packets hit the default case, gve_tx_add_skb_dqo() fails and gve_try_tx_skb() drops them, counting them in tx_dropped. These packets do reach the driver: tcp_gso_segment() passes DODGY skbs through unsegmented to devices that support TSO, after recomputing gso_segs, so drivers must tolerate the bit. This breaks virtual machines behind a tap on GCE instances using the DQO queue formats. Every TSO packet forwarded from a guest (gso_type SKB_GSO_TCPV4 | SKB_GSO_DODGY) is dropped, and guest uploads slow to a crawl of retransmissions or stall entirely, while the host's own TSO traffic (gso_type SKB_GSO_TCPV4) is unaffected. On an n4 instance (DQO-QPL) with a Cloud Hypervisor guest, a 64 MB upload from the guest went from a 60 s timeout at ~0.9 MB/s to 0.19 s with this change, with tx_dropped no longer increasing. Host TCP with ECN is hit as well: gve advertises NETIF_F_TSO_ECN, so a TSO packet carrying CWR has SKB_GSO_TCP_ECN set and is dropped too. Restore the bitmask test that commit 1b9f75634441 ("gve: ignore nonrelevant GSO type bits when processing TSO headers") introduced for the same problem, keeping the UDP GSO support. While here, reload shinfo after skb_cow_head(). If the head was cloned, pskb_expand_head() moves skb_shared_info to the new head, and the pointer cached at function entry can then refer to memory that another clone frees. Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format") Signed-off-by: Hannu Varjoranta <hannu@varjosoft.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260925115237.56465-1-hannu@varjosoft.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> 
Since commit 014c607f86ab ("gve: add support for UDP GSO for DQO
format"), gve_prep_tso() matches shinfo->gso_type exactly. gso_type is
a bitmask, though: SKB_GSO_DODGY is set on every GSO packet that comes
from tun/tap, packet sockets or other untrusted sources, and
SKB_GSO_TCP_ECN and SKB_GSO_TCP_FIXEDID can be set as well. Such packets
hit the default case, gve_tx_add_skb_dqo() fails and gve_try_tx_skb()
drops them, counting them in tx_dropped.

These packets do reach the driver: tcp_gso_segment() passes DODGY skbs
through unsegmented to devices that support TSO, after recomputing
gso_segs, so drivers must tolerate the bit.

This breaks virtual machines behind a tap on GCE instances using the DQO
queue formats. Every TSO packet forwarded from a guest (gso_type
SKB_GSO_TCPV4 | SKB_GSO_DODGY) is dropped, and guest uploads slow to a
crawl of retransmissions or stall entirely, while the host's own TSO
traffic (gso_type SKB_GSO_TCPV4) is unaffected. On an n4 instance
(DQO-QPL) with a Cloud Hypervisor guest, a 64 MB upload from the guest
went from a 60 s timeout at ~0.9 MB/s to 0.19 s with this change, with
tx_dropped no longer increasing.

Host TCP with ECN is hit as well: gve advertises NETIF_F_TSO_ECN, so a
TSO packet carrying CWR has SKB_GSO_TCP_ECN set and is dropped too.

Restore the bitmask test that commit 1b9f75634441 ("gve: ignore
nonrelevant GSO type bits when processing TSO headers") introduced for
the same problem, keeping the UDP GSO support.

While here, reload shinfo after skb_cow_head(). If the head was cloned,
pskb_expand_head() moves skb_shared_info to the new head, and the
pointer cached at function entry can then refer to memory that another
clone frees.

Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format")
Signed-off-by: Hannu Varjoranta <hannu@varjosoft.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ankit Garg <nktgrg@google.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260925115237.56465-1-hannu@varjosoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
gve: DQO: reject TSO packets with an out of range MSS 2026-09-24T17:56:59+00:00 Eric Dumazet edumazet@google.com 2026-09-24T00:42:52+00:00 296c83b5ccc808c080865eb20fd7a477b0355bb7 gve_prep_tso() notes that the device requires the MSS to be <= 9728, but does not enforce it, assuming the 9K MTU enforced by the hypervisor and the 64KB limit on TSO sizes are enough. This does not hold for packets that were not generated locally. A guest behind a tap, or any packet socket user, can provide an arbitrary gso_size in virtio_net_hdr. Layer 2 forwarding does not check the MTU for GSO packets (is_skb_forwardable()), and gso_features_check() only bounds skb->len and gso_segs, never gso_size. Such a packet reaches gve_tx_fill_tso_ctx_desc(), which puts gso_size into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gso_size of 16384 is silently turned into an MSS of zero. Drop these packets from gve_prep_tso(), and make sure that gve_features_check_dqo() leaves their GSO bits alone: skb_segment() splits at gso_size regardless of the MTU, so falling back to software segmentation would give the device non TSO packets bigger than the 9728 bytes it supports. Note that the device can still be given oversized non TSO packets when the stack segments in software for other reasons, for instance after TSO has been disabled with ethtool. This is a generic issue, because the MTU check is skipped for GSO packets in the forwarding path, and is addressed separately. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260924004252.1196328-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
gve_prep_tso() notes that the device requires the MSS to be <= 9728,
but does not enforce it, assuming the 9K MTU enforced by the hypervisor
and the 64KB limit on TSO sizes are enough.

This does not hold for packets that were not generated locally.
A guest behind a tap, or any packet socket user, can provide an
arbitrary gso_size in virtio_net_hdr. Layer 2 forwarding does not check
the MTU for GSO packets (is_skb_forwardable()), and gso_features_check()
only bounds skb->len and gso_segs, never gso_size.

Such a packet reaches gve_tx_fill_tso_ctx_desc(), which puts gso_size
into the mss field of the TSO context descriptor. This field is 14 bits
wide, so a gso_size of 16384 is silently turned into an MSS of zero.

Drop these packets from gve_prep_tso(), and make sure that
gve_features_check_dqo() leaves their GSO bits alone: skb_segment()
splits at gso_size regardless of the MTU, so falling back to software
segmentation would give the device non TSO packets bigger than the
9728 bytes it supports.

Note that the device can still be given oversized non TSO packets when
the stack segments in software for other reasons, for instance after
TSO has been disabled with ethtool. This is a generic issue, because
the MTU check is skipped for GSO packets in the forwarding path, and
is addressed separately.

Fixes: a57e5de476be ("gve: DQO: Add TX path")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260924004252.1196328-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: fix TX drop when GSO MSS is too small for hw 2026-09-24T17:56:59+00:00 Eddie Phillips eddiephillips@google.com 2026-09-24T00:42:51+00:00 3b430ea6234087957b0d3cd181e3116722b59819 The device has a strict requirement that the minimum MSS (gso_size) for TSO/GSO packets must be at least 88 bytes. If a packet below this threshold is pushed to the hardware, it can cause hardware to silently drop the packet, leading to increased latency and retransmissions. Currently, this is validated too late in the transmit pipeline (gve_prep_tso), leading to silent drops. Fix this by moving the validation into the .ndo_features_check callback (gve_features_check_dqo). If we detect a GSO packet with a gso_size smaller than GVE_TX_MIN_TSO_MSS_DQO, we clear the GSO feature flags for this packet. Fixes: a57e5de476be ("gve: DQO: Add TX path") Signed-off-by: Eddie Phillips <eddiephillips@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260924004252.1196328-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
The device has a strict requirement that the minimum MSS
(gso_size) for TSO/GSO packets must be at least 88 bytes. If a packet
below this threshold is pushed to the hardware, it can cause
hardware to silently drop the packet, leading to increased latency
and retransmissions.

Currently, this is validated too late in the transmit pipeline
(gve_prep_tso), leading to silent drops.

Fix this by moving the validation into the .ndo_features_check
callback (gve_features_check_dqo). If we detect a GSO packet with
a gso_size smaller than GVE_TX_MIN_TSO_MSS_DQO, we clear the GSO
feature flags for this packet.

Fixes: a57e5de476be ("gve: DQO: Add TX path")
Signed-off-by: Eddie Phillips <eddiephillips@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260924004252.1196328-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: DQO: fix header length used by gve_can_send_tso() for UDP GSO 2026-09-24T17:51:29+00:00 Eric Dumazet edumazet@google.com 2026-09-23T14:59:42+00:00 83769c23fb1879edc916a526ba424285033baf2d gve_can_send_tso() computes how many buffers each segment of a GSO packet would span, and for this it needs the length of the headers that the device replicates in front of every segment. It unconditionally uses skb_tcp_all_headers(), which reads the doff field of the TCP header. SKB_GSO_UDP_L4 packets have no TCP header: tcp_hdrlen() then reads one byte of the UDP payload, and header_len can be anything in [0, 60] instead of the transport offset plus the eight bytes of the UDP header that gve_prep_tso() programs into the TSO context descriptor. A wrong header length shifts all the segment boundaries computed in the loop, so the number of buffers per segment can be over or under estimated. In the first case, GSO is needlessly disabled for this packet by gve_features_check_dqo() and the stack has to segment it. In the second case, the driver hands the device a packet whose segments span more than GVE_TX_MAX_DATA_DESCS buffers. Use the UDP header length for SKB_GSO_UDP_L4 packets, matching what gve_prep_tso() does. Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format") Closes: https://lore.kernel.org/netdev/CANn89i+MS4L60sFQ49=-f-mibeveUfcrpVkD5X+Qy6SOnEpd6w@mail.gmail.com/ Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Ankit Garg <nktgrg@google.com> Cc: Harshitha Ramamurthy <hramamurthy@google.com> Cc: Joshua Washington <joshwash@google.com> Cc: Willem de Bruijn <willemb@google.com> Reviewed-by: Ankit Garg <nktgrg@google.com> Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260923145942.731365-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
gve_can_send_tso() computes how many buffers each segment of a GSO
packet would span, and for this it needs the length of the headers
that the device replicates in front of every segment.

It unconditionally uses skb_tcp_all_headers(), which reads the doff
field of the TCP header. SKB_GSO_UDP_L4 packets have no TCP header:
tcp_hdrlen() then reads one byte of the UDP payload, and header_len
can be anything in [0, 60] instead of the transport offset plus the
eight bytes of the UDP header that gve_prep_tso() programs into the
TSO context descriptor.

A wrong header length shifts all the segment boundaries computed in
the loop, so the number of buffers per segment can be over or under
estimated. In the first case, GSO is needlessly disabled for this
packet by gve_features_check_dqo() and the stack has to segment it.
In the second case, the driver hands the device a packet whose
segments span more than GVE_TX_MAX_DATA_DESCS buffers.

Use the UDP header length for SKB_GSO_UDP_L4 packets, matching what
gve_prep_tso() does.

Fixes: 014c607f86ab ("gve: add support for UDP GSO for DQO format")
Closes: https://lore.kernel.org/netdev/CANn89i+MS4L60sFQ49=-f-mibeveUfcrpVkD5X+Qy6SOnEpd6w@mail.gmail.com/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ankit Garg <nktgrg@google.com>
Cc: Harshitha Ramamurthy <hramamurthy@google.com>
Cc: Joshua Washington <joshwash@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Reviewed-by: Ankit Garg <nktgrg@google.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260923145942.731365-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: add a few helper functions to set device properties 2026-08-18T01:40:08+00:00 Harshitha Ramamurthy hramamurthy@google.com 2026-08-14T02:13:53+00:00 69886e8085ab66be8e5e1ea1ef3aeaa25c8dfa6c For the mailbox ABI, device properties will come from a different source compared to the AdminQ mode. To accommodate the new source when the mailbox ABI is added, add a few helper functions to set a few device properties. Those functions are: - gve_set_queue_properties() to set no. of pages for QPL mode and number of queues in general - gve_set_mtu() - gve_set_mac() This is just code movement, no functional change. Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20260814021406.3044324-4-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
For the mailbox ABI, device properties will come from a different
source compared to the AdminQ mode. To accommodate the new source
when the mailbox ABI is added, add a few helper functions to set a
few device properties. Those functions are:

- gve_set_queue_properties() to set no. of pages for QPL mode and
  number of queues in general
- gve_set_mtu()
- gve_set_mac()

This is just code movement, no functional change.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20260814021406.3044324-4-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: refactor initialization with helper functions 2026-08-18T01:40:08+00:00 Harshitha Ramamurthy hramamurthy@google.com 2026-08-14T02:13:52+00:00 94afe5cebcd2bc32d774bfe603a8259680e9e870 In the interest of commonizing code, refactor gve_probe() and gve_init_priv() with a few helper functions that can be expanded and utilized in upcoming patches that add the mailbox ABI to the driver. The helper functions are: - gve_set_num_ntfy_blks() - gve_set_num_queues() Reorder code to combine lines that accomplish a similar objective like setting defaults. Move setting HW-GRO and UDP GSO support out of an Adminq method into gve_init_priv(). These changes are just code movement, no functional change. Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20260814021406.3044324-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
In the interest of commonizing code, refactor gve_probe()
and gve_init_priv() with a few helper functions that can
be expanded and utilized in upcoming patches that add the
mailbox ABI to the driver. The helper functions are:

- gve_set_num_ntfy_blks()
- gve_set_num_queues()

Reorder code to combine lines that accomplish a similar objective
like setting defaults. Move setting HW-GRO and UDP GSO support out
of an Adminq method into gve_init_priv().

These changes are just code movement, no functional change.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20260814021406.3044324-3-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: don't pass in unused parameter to gve_adminq_free 2026-08-18T01:40:08+00:00 Harshitha Ramamurthy hramamurthy@google.com 2026-08-14T02:13:51+00:00 063aeece6053c48832c4d12cff39fb0645383d28 Clean up gve_adminq_free to not take in an unused parameter. Reviewed-by: Willem de Bruijn <willemb@google.com> Reviewed-by: Jordan Rhee <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://patch.msgid.link/20260814021406.3044324-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Clean up gve_adminq_free to not take in an unused parameter.

Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20260814021406.3044324-2-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 2026-08-13T18:00:14+00:00 Jakub Kicinski kuba@kernel.org 2026-08-06T18:51:42+00:00 3da8c3c8b8fa99505624b65ef590482f48e766b6 Cross-merge networking fixes after downstream PR (net-7.2-rc8). No conflicts. Adjacent changes: drivers/net/ethernet/wangxun/ngbe/ngbe_main.c 5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling") d661abdc30c2 ("net: ngbe: correct misleading interrupt comment") drivers/net/ipvlan/ipvlan_main.c e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") 00a40d809207 ("ipvlan: Support per-netns netdev unregistration.") Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Cross-merge networking fixes after downstream PR (net-7.2-rc8).

No conflicts.

Adjacent changes:

drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
  5f3a13e0bb5e ("net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling")
  d661abdc30c2 ("net: ngbe: correct misleading interrupt comment")

drivers/net/ipvlan/ipvlan_main.c
  e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev")
  00a40d809207 ("ipvlan: Support per-netns netdev unregistration.")

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: fix NULL dereference due to missing ptp adjfine 2026-08-12T01:26:04+00:00 Jordan Rhee jordanrhee@google.com 2026-08-07T22:43:15+00:00 3992ced109c70b771efad9e51ae68e5c7a04dea3 Fix NULL dereference due to missing implementation of adjfine, which can be triggered from usermode as follows: sudo ./testptp -d /dev/ptp0 -f 0 [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 552.061946] Call Trace: [ 552.064487] <TASK> [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0 [ 552.070874] ? get_clock_desc+0x6b/0xb0 [ 552.074825] pc_clock_adjtime+0x78/0xc0 [ 552.078755] __do_sys_clock_adjtime+0x85/0x110 [ 552.083293] do_syscall_64+0xea/0x610 Cc: stable@vger.kernel.org Fixes: acd16380523b ("gve: Add initial PTP device support") Signed-off-by: Jordan Rhee <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
Fix NULL dereference due to missing implementation of adjfine, which can
be triggered from usermode as follows:

sudo ./testptp -d /dev/ptp0 -f 0
[  551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
[  552.061946] Call Trace:
[  552.064487]  <TASK>
[  552.066681]  ptp_clock_adjtime+0x1c0/0x2c0
[  552.070874]  ? get_clock_desc+0x6b/0xb0
[  552.074825]  pc_clock_adjtime+0x78/0xc0
[  552.078755]  __do_sys_clock_adjtime+0x85/0x110
[  552.083293]  do_syscall_64+0xea/0x610

Cc: stable@vger.kernel.org
Fixes: acd16380523b ("gve: Add initial PTP device support")
Signed-off-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260807224315.234152-3-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gve: fix zero-length skb frag with header-split 2026-08-12T01:26:04+00:00 Jordan Rhee jordanrhee@google.com 2026-08-07T22:43:14+00:00 6bf14575c65569dcded90ef78afb8a6d57323f04 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 <pkaligineedi@google.com> Co-developed-by: Ziwei Xiao <ziweixiao@google.com> Signed-off-by: Ziwei Xiao <ziweixiao@google.com> Signed-off-by: Jordan Rhee <jordanrhee@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Link: https://patch.msgid.link/20260807224315.234152-2-hramamurthy@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> 
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 <pkaligineedi@google.com>
Co-developed-by: Ziwei Xiao <ziweixiao@google.com>
Signed-off-by: Ziwei Xiao <ziweixiao@google.com>
Signed-off-by: Jordan Rhee <jordanrhee@google.com>
Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260807224315.234152-2-hramamurthy@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>