• Vladimir Oltean's avatar
    net: dsa: mv88e6xxx: keep the pvid at 0 when VLAN-unaware · 8b6836d8
    Vladimir Oltean authored
    The VLAN support in mv88e6xxx has a loaded history. Commit 2ea7a679
    ("net: dsa: Don't add vlans when vlan filtering is disabled") noticed
    some issues with VLAN and decided the best way to deal with them was to
    make the DSA core ignore VLANs added by the bridge while VLAN awareness
    is turned off. Those issues were never explained, just presented as
    "at least one corner case".
    
    That approach had problems of its own, presented by
    commit 54a0ed0d ("net: dsa: provide an option for drivers to always
    receive bridge VLANs") for the DSA core, followed by
    commit 1fb74191 ("net: dsa: mv88e6xxx: fix vlan setup") which
    applied ds->configure_vlan_while_not_filtering = true for mv88e6xxx in
    particular.
    
    We still don't know what corner case Andrew saw when he wrote
    commit 2ea7a679 ("net: dsa: Don't add vlans when vlan filtering is
    disabled"), but Tobias now reports that when we use TX forwarding
    offload, pinging an external station from the bridge device is broken if
    the front-facing DSA user port has flooding turned off. The full
    description is in the link below, but for short, when a mv88e6xxx port
    is under a VLAN-unaware bridge, it inherits that bridge's pvid.
    So packets ingressing a user port will be classified to e.g. VID 1
    (assuming that value for the bridge_default_pvid), whereas when
    tag_dsa.c xmits towards a user port, it always sends packets using a VID
    of 0 if that port is standalone or under a VLAN-unaware bridge - or at
    least it did so prior to commit d82f8ab0 ("net: dsa: tag_dsa:
    offload the bridge forwarding process").
    
    In any case, when there is a conversation between the CPU and a station
    connected to a user port, the station's MAC address is learned in VID 1
    but the CPU tries to transmit through VID 0. The packets reach the
    intended station, but via flooding and not by virtue of matching the
    existing ATU entry.
    
    DSA has established (and enforced in other drivers: sja1105, felix,
    mt7530) that a VLAN-unaware port should use a private pvid, and not
    inherit the one from the bridge. The bridge's pvid should only be
    inherited when that bridge is VLAN-aware, so all state transitions need
    to be handled. On the other hand, all bridge VLANs should sit in the VTU
    starting with the moment when the bridge offloads them via switchdev,
    they are just not used.
    
    This solves the problem that Tobias sees because packets ingressing on
    VLAN-unaware user ports now get classified to VID 0, which is also the
    VID used by tag_dsa.c on xmit.
    
    Fixes: d82f8ab0 ("net: dsa: tag_dsa: offload the bridge forwarding process")
    Link: https://patchwork.kernel.org/project/netdevbpf/patch/20211003222312.284175-2-vladimir.oltean@nxp.com/#24491503Reported-by: default avatarTobias Waldekranz <tobias@waldekranz.com>
    Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
    8b6836d8
port.c 39.4 KB