Skip to content
  • Jay Vosburgh's avatar
    net/core: Handle csum for CHECKSUM_COMPLETE VXLAN forwarding · 2c26d34b
    Jay Vosburgh authored
    
    
    When using VXLAN tunnels and a sky2 device, I have experienced
    checksum failures of the following type:
    
    [ 4297.761899] eth0: hw csum failure
    [...]
    [ 4297.765223] Call Trace:
    [ 4297.765224]  <IRQ>  [<ffffffff8172f026>] dump_stack+0x46/0x58
    [ 4297.765235]  [<ffffffff8162ba52>] netdev_rx_csum_fault+0x42/0x50
    [ 4297.765238]  [<ffffffff8161c1a0>] ? skb_push+0x40/0x40
    [ 4297.765240]  [<ffffffff8162325c>] __skb_checksum_complete+0xbc/0xd0
    [ 4297.765243]  [<ffffffff8168c602>] tcp_v4_rcv+0x2e2/0x950
    [ 4297.765246]  [<ffffffff81666ca0>] ? ip_rcv_finish+0x360/0x360
    
    	These are reliably reproduced in a network topology of:
    
    container:eth0 == host(OVS VXLAN on VLAN) == bond0 == eth0 (sky2) -> switch
    
    	When VXLAN encapsulated traffic is received from a similarly
    configured peer, the above warning is generated in the receive
    processing of the encapsulated packet.  Note that the warning is
    associated with the container eth0.
    
            The skbs from sky2 have ip_summed set to CHECKSUM_COMPLETE, and
    because the packet is an encapsulated Ethernet frame, the checksum
    generated by the hardware includes the inner protocol and Ethernet
    headers.
    
    	The receive code is careful to update the skb->csum, except in
    __dev_forward_skb, as called by dev_forward_skb.  __dev_forward_skb
    calls eth_type_trans, which in turn calls skb_pull_inline(skb, ETH_HLEN)
    to skip over the Ethernet header, but does not update skb->csum when
    doing so.
    
    	This patch resolves the problem by adding a call to
    skb_postpull_rcsum to update the skb->csum after the call to
    eth_type_trans.
    
    Signed-off-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    2c26d34b