Commit 488089055b61 for kernel

commit 488089055b61be8f7e97817d4608844f0fba2648
Merge: 83769c23fb18 296c83b5ccc8
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Thu Sep 24 10:57:01 2026 -0700

    Merge branch 'gve-dqo-fix-handling-of-out-of-range-tso-mss'

    Eric Dumazet says:

    ====================
    gve: DQO: fix handling of out of range TSO MSS

    The DQO TX path assumes that the MSS of a TSO packet is within the
    range supported by the device, [88, 9728].

    This holds for locally generated traffic, but not for packets coming
    from a tap or from a packet socket: virtio_net_hdr_to_skb() takes
    gso_size from user space and only enforces a minimum, layer 2
    forwarding does not check the MTU of GSO packets, and
    gso_features_check() bounds skb->len and gso_segs but never gso_size.

    Patch 1, from Eddie Phillips, deals with the lower bound. It moves the
    existing test out of gve_prep_tso() into gve_features_check_dqo(), so
    that these packets are segmented in software instead of being dropped.

    Patch 2 deals with the upper bound, which is currently not checked at
    all. gve_tx_fill_tso_ctx_desc() stores gso_size into a 14 bits wide
    field, so that an MSS of 16384 silently becomes zero. Falling back to
    software segmentation is not an option here, because skb_segment()
    splits at gso_size regardless of the MTU, and would only replace an
    invalid TSO packet by non TSO packets larger than the 9728 bytes the
    device supports. These packets are dropped instead.

    As noted in patch 2, oversized non TSO packets can still reach the
    device whenever the stack segments in software. This is not specific
    to gve and is better fixed in the core, so a patch for
    __is_skb_forwardable() will be sent separately for net-next.
    ====================

    Link: https://patch.msgid.link/20260924004252.1196328-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>