• Toke Høiland-Jørgensen's avatar
    sched: consistently handle layer3 header accesses in the presence of VLANs · 9fd235ff
    Toke Høiland-Jørgensen authored
    [ Upstream commit d7bf2ebe ]
    
    There are a couple of places in net/sched/ that check skb->protocol and act
    on the value there. However, in the presence of VLAN tags, the value stored
    in skb->protocol can be inconsistent based on whether VLAN acceleration is
    enabled. The commit quoted in the Fixes tag below fixed the users of
    skb->protocol to use a helper that will always see the VLAN ethertype.
    
    However, most of the callers don't actually handle the VLAN ethertype, but
    expect to find the IP header type in the protocol field. This means that
    things like changing the ECN field, or parsing diffserv values, stops
    working if there's a VLAN tag, or if there are multiple nested VLAN
    tags (QinQ).
    
    To fix this, change the helper to take an argument that indicates whether
    the caller wants to skip the VLAN tags or not. When skipping VLAN tags, we
    make sure to skip all of them, so behaviour is consistent even in QinQ
    mode.
    
    To make the helper usable from the ECN code, move it to if_vlan.h instead
    of pkt_sched.h.
    
    v3:
    - Remove empty lines
    - Move vlan variable definitions inside loop in skb_protocol()
    - Also use skb_protocol() helper in IP{,6}_ECN_decapsulate() and
      bpf_skb_ecn_set_ce()
    
    v2:
    - Use eth_type_vlan() helper in skb_protocol()
    - Also fix code that reads skb->protocol directly
    - Change a couple of 'if/else if' statements to switch constructs to avoid
      calling the helper twice
    Reported-by: default avatarIlya Ponetayev <i.ponetaev@ndmsystems.com>
    Fixes: d8b9605d ("net: sched: fix skb->protocol use in case of accelerated vlan path")
    Signed-off-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    9fd235ff
cls_flower.c 57.5 KB