1. 18 3月, 2022 1 次提交
    • T
      net: bridge: mst: Multiple Spanning Tree (MST) mode · ec7328b5
      Tobias Waldekranz 提交于
      Allow the user to switch from the current per-VLAN STP mode to an MST
      mode.
      
      Up to this point, per-VLAN STP states where always isolated from each
      other. This is in contrast to the MSTP standard (802.1Q-2018, Clause
      13.5), where VLANs are grouped into MST instances (MSTIs), and the
      state is managed on a per-MSTI level, rather that at the per-VLAN
      level.
      
      Perhaps due to the prevalence of the standard, many switching ASICs
      are built after the same model. Therefore, add a corresponding MST
      mode to the bridge, which we can later add offloading support for in a
      straight-forward way.
      
      For now, all VLANs are fixed to MSTI 0, also called the Common
      Spanning Tree (CST). That is, all VLANs will follow the port-global
      state.
      
      Upcoming changes will make this actually useful by allowing VLANs to
      be mapped to arbitrary MSTIs and allow individual MSTI states to be
      changed.
      Signed-off-by: NTobias Waldekranz <tobias@waldekranz.com>
      Acked-by: NNikolay Aleksandrov <razor@blackwall.org>
      Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      ec7328b5
  2. 23 2月, 2022 1 次提交
  3. 25 8月, 2021 1 次提交
  4. 20 7月, 2021 2 次提交
  5. 14 5月, 2021 1 次提交
  6. 11 3月, 2021 1 次提交
  7. 10 1月, 2021 1 次提交
  8. 22 11月, 2020 1 次提交
  9. 31 10月, 2020 1 次提交
  10. 30 10月, 2020 1 次提交
  11. 11 5月, 2020 1 次提交
  12. 28 4月, 2020 1 次提交
  13. 24 1月, 2020 1 次提交
    • N
      net: bridge: vlan: add per-vlan state · a580c76d
      Nikolay Aleksandrov 提交于
      The first per-vlan option added is state, it is needed for EVPN and for
      per-vlan STP. The state allows to control the forwarding on per-vlan
      basis. The vlan state is considered only if the port state is forwarding
      in order to avoid conflicts and be consistent. br_allowed_egress is
      called only when the state is forwarding, but the ingress case is a bit
      more complicated due to the fact that we may have the transition between
      port:BR_STATE_FORWARDING -> vlan:BR_STATE_LEARNING which should still
      allow the bridge to learn from the packet after vlan filtering and it will
      be dropped after that. Also to optimize the pvid state check we keep a
      copy in the vlan group to avoid one lookup. The state members are
      modified with *_ONCE() to annotate the lockless access.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a580c76d
  14. 05 11月, 2019 1 次提交
    • N
      net: bridge: fdb: eliminate extra port state tests from fast-path · 5d1fcaf3
      Nikolay Aleksandrov 提交于
      When commit df1c0b84 ("[BRIDGE]: Packets leaking out of
      disabled/blocked ports.") introduced the port state tests in
      br_fdb_update() it was to avoid learning/refreshing from STP BPDUs, it was
      also used to avoid learning/refreshing from user-space with NTF_USE. Those
      two tests are done for every packet entering the bridge if it's learning,
      but for the fast-path we already have them checked in br_handle_frame() and
      is unnecessary to do it again. Thus push the checks to the unlikely cases
      and drop them from br_fdb_update(), the new nbp_state_should_learn() helper
      is used to determine if the port state allows br_fdb_update() to be called.
      The two places which need to do it manually are:
       - user-space add call with NTF_USE set
       - link-local packet learning done in __br_handle_local_finish()
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d1fcaf3
  15. 02 11月, 2019 1 次提交
  16. 30 10月, 2019 1 次提交
  17. 04 7月, 2019 1 次提交
  18. 03 7月, 2019 1 次提交
  19. 31 5月, 2019 1 次提交
  20. 17 4月, 2019 1 次提交
    • N
      net: bridge: fix per-port af_packet sockets · 3b2e2904
      Nikolay Aleksandrov 提交于
      When the commit below was introduced it changed two visible things:
       - the skb was no longer passed through the protocol handlers with the
         original device
       - the skb was passed up the stack with skb->dev = bridge
      
      The first change broke af_packet sockets on bridge ports. For example we
      use them for hostapd which listens for ETH_P_PAE packets on the ports.
      We discussed two possible fixes:
       - create a clone and pass it through NF_HOOK(), act on the original skb
         based on the result
       - somehow signal to the caller from the okfn() that it was called,
         meaning the skb is ok to be passed, which this patch is trying to
         implement via returning 1 from the bridge link-local okfn()
      
      Note that we rely on the fact that NF_QUEUE/STOLEN would return 0 and
      drop/error would return < 0 thus the okfn() is called only when the
      return was 1, so we signal to the caller that it was called by preserving
      the return value from nf_hook().
      
      Fixes: 8626c56c ("bridge: fix potential use-after-free when hook returns QUEUE or STOLEN verdict")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b2e2904
  21. 16 4月, 2019 1 次提交
  22. 12 4月, 2019 3 次提交
  23. 28 11月, 2018 1 次提交
  24. 27 9月, 2018 1 次提交
  25. 26 5月, 2018 1 次提交
  26. 10 11月, 2017 1 次提交
  27. 09 10月, 2017 2 次提交
  28. 29 9月, 2017 1 次提交
    • N
      net: bridge: add per-port group_fwd_mask with less restrictions · 5af48b59
      Nikolay Aleksandrov 提交于
      We need to be able to transparently forward most link-local frames via
      tunnels (e.g. vxlan, qinq). Currently the bridge's group_fwd_mask has a
      mask which restricts the forwarding of STP and LACP, but we need to be able
      to forward these over tunnels and control that forwarding on a per-port
      basis thus add a new per-port group_fwd_mask option which only disallows
      mac pause frames to be forwarded (they're always dropped anyway).
      The patch does not change the current default situation - all of the others
      are still restricted unless configured for forwarding.
      We have successfully tested this patch with LACP and STP forwarding over
      VxLAN and qinq tunnels.
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5af48b59
  29. 14 7月, 2017 1 次提交
  30. 14 3月, 2017 1 次提交
  31. 15 2月, 2017 1 次提交
  32. 08 2月, 2017 1 次提交
  33. 07 2月, 2017 1 次提交
  34. 04 2月, 2017 1 次提交
  35. 02 9月, 2016 2 次提交