On Tue, Mar 30, 2021 at 6:29 AM Paolo Abeni <pab...@redhat.com> wrote: > > When UDP packets generated locally by a socket with UDP_SEGMENT > traverse the following path: > > UDP tunnel(xmit) -> veth (segmentation) -> veth (gro) -> > UDP tunnel (rx) -> UDP socket (no UDP_GRO) > > ip_summed will be set to CHECKSUM_PARTIAL at creation time and > such checksum mode will be preserved in the above path up to the > UDP tunnel receive code where we have: > > __iptunnel_pull_header() -> skb_pull_rcsum() -> > skb_postpull_rcsum() -> __skb_postpull_rcsum() > > The latter will convert the skb to CHECKSUM_NONE. > > The UDP GSO packet will be later segmented as part of the rx socket > receive operation, and will present a CHECKSUM_NONE after segmentation. > > Additionally the segmented packets UDP CB still refers to the original > GSO packet len. Overall that causes unexpected/wrong csum validation > errors later in the UDP receive path. > > We could possibly address the issue with some additional checks and > csum mangling in the UDP tunnel code. Since the issue affects only > this UDP receive slow path, let's set a suitable csum status there. > > Note that SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST packets lacking an UDP > encapsulation present a valid checksum when landing to udp_queue_rcv_skb(), > as the UDP checksum has been validated by the GRO engine. > > v2 -> v3: > - even more verbose commit message and comments > > v1 -> v2: > - restrict the csum update to the packets strictly needing them > - hopefully clarify the commit message and code comments > > Signed-off-by: Paolo Abeni <pab...@redhat.com>
Reviewed-by: Willem de Bruijn <will...@google.com>
