1. 15 1月, 2020 1 次提交
  2. 15 12月, 2019 1 次提交
  3. 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
  4. 02 11月, 2019 1 次提交
  5. 30 10月, 2019 6 次提交
  6. 18 8月, 2019 1 次提交
  7. 06 8月, 2019 1 次提交
    • N
      net: bridge: move default pvid init/deinit to NETDEV_REGISTER/UNREGISTER · 091adf9b
      Nikolay Aleksandrov 提交于
      Most of the bridge device's vlan init bugs come from the fact that its
      default pvid is created at the wrong time, way too early in ndo_init()
      before the device is even assigned an ifindex. It introduces a bug when the
      bridge's dev_addr is added as fdb during the initial default pvid creation
      the notification has ifindex/NDA_MASTER both equal to 0 (see example below)
      which really makes no sense for user-space[0] and is wrong.
      Usually user-space software would ignore such entries, but they are
      actually valid and will eventually have all necessary attributes.
      It makes much more sense to send a notification *after* the device has
      registered and has a proper ifindex allocated rather than before when
      there's a chance that the registration might still fail or to receive
      it with ifindex/NDA_MASTER == 0. Note that we can remove the fdb flush
      from br_vlan_flush() since that case can no longer happen. At
      NETDEV_REGISTER br->default_pvid is always == 1 as it's initialized by
      br_vlan_init() before that and at NETDEV_UNREGISTER it can be anything
      depending why it was called (if called due to NETDEV_REGISTER error
      it'll still be == 1, otherwise it could be any value changed during the
      device life time).
      
      For the demonstration below a small change to iproute2 for printing all fdb
      notifications is added, because it contained a workaround not to show
      entries with ifindex == 0.
      Command executed while monitoring: $ ip l add br0 type bridge
      Before (both ifindex and master == 0):
      $ bridge monitor fdb
      36:7e:8a:b3:56:ba dev * vlan 1 master * permanent
      
      After (proper br0 ifindex):
      $ bridge monitor fdb
      e6:2a:ae:7a:b7:48 dev br0 vlan 1 master br0 permanent
      
      v4: move only the default pvid init/deinit to NETDEV_REGISTER/UNREGISTER
      v3: send the correct v2 patch with all changes (stub should return 0)
      v2: on error in br_vlan_init set br->vlgrp to NULL and return 0 in
          the br_vlan_bridge_event stub when bridge vlans are disabled
      
      [0] https://bugzilla.kernel.org/show_bug.cgi?id=204389Reported-by: Nmichael-dev <michael-dev@fami-braun.de>
      Fixes: 5be5a2df ("bridge: Add filtering support for default_pvid")
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: NRoopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      091adf9b
  8. 01 8月, 2019 1 次提交
  9. 31 5月, 2019 2 次提交
    • P
      netfilter: bridge: add connection tracking system · 3c171f49
      Pablo Neira Ayuso 提交于
      This patch adds basic connection tracking support for the bridge,
      including initial IPv4 support.
      
      This patch register two hooks to deal with the bridge forwarding path,
      one from the bridge prerouting hook to call nf_conntrack_in(); and
      another from the bridge postrouting hook to confirm the entry.
      
      The conntrack bridge prerouting hook defragments packets before passing
      them to nf_conntrack_in() to look up for an existing entry, otherwise a
      new entry is allocated and it is attached to the skbuff. The conntrack
      bridge postrouting hook confirms new conntrack entries, ie. if this is
      the first packet seen, then it adds the entry to the hashtable and (if
      needed) it refragments the skbuff into the original fragments, leaving
      the geometry as is if possible. Exceptions are linearized skbuffs, eg.
      skbuffs that are passed up to nfqueue and conntrack helpers, as well as
      cloned skbuff for the local delivery (eg. tcpdump), also in case of
      bridge port flooding (cloned skbuff too).
      
      The packet defragmentation is done through the ip_defrag() call.  This
      forces us to save the bridge control buffer, reset the IP control buffer
      area and then restore it after call. This function also bumps the IP
      fragmentation statistics, it would be probably desiderable to have
      independent statistics for the bridge defragmentation/refragmentation.
      The maximum fragment length is stored in the control buffer and it is
      used to refragment the skbuff from the postrouting path.
      
      The new fraglist splitter and fragment transformer APIs are used to
      implement the bridge refragmentation code. The br_ip_fragment() function
      drops the packet in case the maximum fragment size seen is larger than
      the output port MTU.
      
      This patchset follows the principle that conntrack should not drop
      packets, so users can do it through policy via invalid state matching.
      
      Like br_netfilter, there is no refragmentation for packets that are
      passed up for local delivery, ie. prerouting -> input path. There are
      calls to nf_reset() already in several spots in the stack since time ago
      already, eg. af_packet, that show that skbuff fraglist handling from the
      netif_rx path is supported already.
      
      The helpers are called from the postrouting hook, before confirmation,
      from there we may see packet floods to bridge ports. Then, although
      unlikely, this may result in exercising the helpers many times for each
      clone. It would be good to explore how to pass all the packets in a list
      to the conntrack hook to do this handle only once for this case.
      
      Thanks to Florian Westphal for handing me over an initial patchset
      version to add support for conntrack bridge.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3c171f49
    • T
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 · 2874c5fd
      Thomas Gleixner 提交于
      Based on 1 normalized pattern(s):
      
        this program is free software you can redistribute it and or modify
        it under the terms of the gnu general public license as published by
        the free software foundation either version 2 of the license or at
        your option any later version
      
      extracted by the scancode license scanner the SPDX license identifier
      
        GPL-2.0-or-later
      
      has been chosen to replace the boilerplate/reference in 3029 file(s).
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NAllison Randal <allison@lohutok.net>
      Cc: linux-spdx@vger.kernel.org
      Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2874c5fd
  10. 20 4月, 2019 1 次提交
    • M
      bridge: support binding vlan dev link state to vlan member bridge ports · 9c0ec2e7
      Mike Manning 提交于
      In the case of vlan filtering on bridges, the bridge may also have the
      corresponding vlan devices as upper devices. A vlan bridge binding mode
      is added to allow the link state of the vlan device to track only the
      state of the subset of bridge ports that are also members of the vlan,
      rather than that of all bridge ports. This mode is set with a vlan flag
      rather than a bridge sysfs so that the 8021q module is aware that it
      should not set the link state for the vlan device.
      
      If bridge vlan is configured, the bridge device event handling results
      in the link state for an upper device being set, if it is a vlan device
      with the vlan bridge binding mode enabled. This also sets a
      vlan_bridge_binding flag so that subsequent UP/DOWN/CHANGE events for
      the ports in that bridge result in a link state update of the vlan
      device if required.
      
      The link state of the vlan device is up if there is at least one bridge
      port that is a vlan member that is admin & oper up, otherwise its oper
      state is IF_OPER_LOWERLAYERDOWN.
      Signed-off-by: NMike Manning <mmanning@vyatta.att-mail.com>
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c0ec2e7
  11. 12 4月, 2019 2 次提交
  12. 30 3月, 2019 1 次提交
  13. 18 1月, 2019 1 次提交
    • P
      net: Add extack argument to ndo_fdb_add() · 87b0984e
      Petr Machata 提交于
      Drivers may not be able to support certain FDB entries, and an error
      code is insufficient to give clear hints as to the reasons of rejection.
      
      In order to make it possible to communicate the rejection reason, extend
      ndo_fdb_add() with an extack argument. Adapt the existing
      implementations of ndo_fdb_add() to take the parameter (and ignore it).
      Pass the extack parameter when invoking ndo_fdb_add() from rtnl_fdb_add().
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      87b0984e
  14. 09 1月, 2019 1 次提交
    • I
      net: bridge: Fix VLANs memory leak · 27973793
      Ido Schimmel 提交于
      When adding / deleting VLANs to / from a bridge port, the bridge driver
      first tries to propagate the information via switchdev and falls back to
      the 8021q driver in case the underlying driver does not support
      switchdev. This can result in a memory leak [1] when VXLAN and mlxsw
      ports are enslaved to the bridge:
      
      $ ip link set dev vxlan0 master br0
      # No mlxsw ports are enslaved to 'br0', so mlxsw ignores the switchdev
      # notification and the bridge driver adds the VLAN on 'vxlan0' via the
      # 8021q driver
      $ bridge vlan add vid 10 dev vxlan0 pvid untagged
      # mlxsw port is enslaved to the bridge
      $ ip link set dev swp1 master br0
      # mlxsw processes the switchdev notification and the 8021q driver is
      # skipped
      $ bridge vlan del vid 10 dev vxlan0
      
      This results in 'struct vlan_info' and 'struct vlan_vid_info' being
      leaked, as they were allocated by the 8021q driver during VLAN addition,
      but never freed as the 8021q driver was skipped during deletion.
      
      Fix this by introducing a new VLAN private flag that indicates whether
      the VLAN was added on the port by switchdev or the 8021q driver. If the
      VLAN was added by the 8021q driver, then we make sure to delete it via
      the 8021q driver as well.
      
      [1]
      unreferenced object 0xffff88822d20b1e8 (size 256):
        comm "bridge", pid 2532, jiffies 4295216998 (age 1188.830s)
        hex dump (first 32 bytes):
          e0 42 97 ce 81 88 ff ff 00 00 00 00 00 00 00 00  .B..............
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000f82d851d>] kmem_cache_alloc_trace+0x1be/0x330
          [<00000000e0178b02>] vlan_vid_add+0x661/0x920
          [<00000000218ebd5f>] __vlan_add+0x1be9/0x3a00
          [<000000006eafa1ca>] nbp_vlan_add+0x8b3/0xd90
          [<000000003535392c>] br_vlan_info+0x132/0x410
          [<00000000aedaa9dc>] br_afspec+0x75c/0x870
          [<00000000f5716133>] br_setlink+0x3dc/0x6d0
          [<00000000aceca5e2>] rtnl_bridge_setlink+0x615/0xb30
          [<00000000a2f2d23e>] rtnetlink_rcv_msg+0x3a3/0xa80
          [<0000000064097e69>] netlink_rcv_skb+0x152/0x3c0
          [<000000008be8d614>] rtnetlink_rcv+0x21/0x30
          [<000000009ab2ca25>] netlink_unicast+0x52f/0x740
          [<00000000e7d9ac96>] netlink_sendmsg+0x9c7/0xf50
          [<000000005d1e2050>] sock_sendmsg+0xbe/0x120
          [<00000000d51426bc>] ___sys_sendmsg+0x778/0x8f0
          [<00000000b9d7b2cc>] __sys_sendmsg+0x112/0x270
      unreferenced object 0xffff888227454308 (size 32):
        comm "bridge", pid 2532, jiffies 4295216998 (age 1188.882s)
        hex dump (first 32 bytes):
          88 b2 20 2d 82 88 ff ff 88 b2 20 2d 82 88 ff ff  .. -...... -....
          81 00 0a 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
        backtrace:
          [<00000000f82d851d>] kmem_cache_alloc_trace+0x1be/0x330
          [<0000000018050631>] vlan_vid_add+0x3e6/0x920
          [<00000000218ebd5f>] __vlan_add+0x1be9/0x3a00
          [<000000006eafa1ca>] nbp_vlan_add+0x8b3/0xd90
          [<000000003535392c>] br_vlan_info+0x132/0x410
          [<00000000aedaa9dc>] br_afspec+0x75c/0x870
          [<00000000f5716133>] br_setlink+0x3dc/0x6d0
          [<00000000aceca5e2>] rtnl_bridge_setlink+0x615/0xb30
          [<00000000a2f2d23e>] rtnetlink_rcv_msg+0x3a3/0xa80
          [<0000000064097e69>] netlink_rcv_skb+0x152/0x3c0
          [<000000008be8d614>] rtnetlink_rcv+0x21/0x30
          [<000000009ab2ca25>] netlink_unicast+0x52f/0x740
          [<00000000e7d9ac96>] netlink_sendmsg+0x9c7/0xf50
          [<000000005d1e2050>] sock_sendmsg+0xbe/0x120
          [<00000000d51426bc>] ___sys_sendmsg+0x778/0x8f0
          [<00000000b9d7b2cc>] __sys_sendmsg+0x112/0x270
      
      Fixes: d70e42b2 ("mlxsw: spectrum: Enable VxLAN enslavement to VLAN-aware bridges")
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Reviewed-by: NPetr Machata <petrm@mellanox.com>
      Cc: Roopa Prabhu <roopa@cumulusnetworks.com>
      Cc: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Cc: bridge@lists.linux-foundation.org
      Acked-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27973793
  15. 17 12月, 2018 1 次提交
  16. 13 12月, 2018 2 次提交
  17. 06 12月, 2018 4 次提交
  18. 28 11月, 2018 2 次提交
    • N
      net: bridge: add no_linklocal_learn bool option · 70e4272b
      Nikolay Aleksandrov 提交于
      Use the new boolopt API to add an option which disables learning from
      link-local packets. The default is kept as before and learning is
      enabled. This is a simple map from a boolopt bit to a bridge private
      flag that is tested before learning.
      
      v2: pass NULL for extack via sysfs
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70e4272b
    • N
      net: bridge: add support for user-controlled bool options · a428afe8
      Nikolay Aleksandrov 提交于
      We have been adding many new bridge options, a big number of which are
      boolean but still take up netlink attribute ids and waste space in the skb.
      Recently we discussed learning from link-local packets[1] and decided
      yet another new boolean option will be needed, thus introducing this API
      to save some bridge nl space.
      The API supports changing the value of multiple boolean options at once
      via the br_boolopt_multi struct which has an optmask (which options to
      set, bit per opt) and optval (options' new values). Future boolean
      options will only be added to the br_boolopt_id enum and then will have
      to be handled in br_boolopt_toggle/get. The API will automatically
      add the ability to change and export them via netlink, sysfs can use the
      single boolopt function versions to do the same. The behaviour with
      failing/succeeding is the same as with normal netlink option changing.
      
      If an option requires mapping to internal kernel flag or needs special
      configuration to be enabled then it should be handled in
      br_boolopt_toggle. It should also be able to retrieve an option's current
      state via br_boolopt_get.
      
      v2: WARN_ON() on unsupported option as that shouldn't be possible and
          also will help catch people who add new options without handling
          them for both set and get. Pass down extack so if an option desires
          it could set it on error and be more user-friendly.
      
      [1] https://www.spinics.net/lists/netdev/msg532698.htmlSigned-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a428afe8
  19. 18 11月, 2018 1 次提交
    • N
      net: bridge: fix vlan stats use-after-free on destruction · 9d332e69
      Nikolay Aleksandrov 提交于
      Syzbot reported a use-after-free of the global vlan context on port vlan
      destruction. When I added per-port vlan stats I missed the fact that the
      global vlan context can be freed before the per-port vlan rcu callback.
      There're a few different ways to deal with this, I've chosen to add a
      new private flag that is set only when per-port stats are allocated so
      we can directly check it on destruction without dereferencing the global
      context at all. The new field in net_bridge_vlan uses a hole.
      
      v2: cosmetic change, move the check to br_process_vlan_info where the
          other checks are done
      v3: add change log in the patch, add private (in-kernel only) flags in a
          hole in net_bridge_vlan struct and use that instead of mixing
          user-space flags with private flags
      
      Fixes: 9163a0fc ("net: bridge: add support for per-port vlan stats")
      Reported-by: syzbot+04681da557a0e49a52e5@syzkaller.appspotmail.com
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d332e69
  20. 09 11月, 2018 1 次提交
  21. 18 10月, 2018 1 次提交
  22. 13 10月, 2018 1 次提交
    • N
      net: bridge: add support for per-port vlan stats · 9163a0fc
      Nikolay Aleksandrov 提交于
      This patch adds an option to have per-port vlan stats instead of the
      default global stats. The option can be set only when there are no port
      vlans in the bridge since we need to allocate the stats if it is set
      when vlans are being added to ports (and respectively free them
      when being deleted). Also bump RTNL_MAX_TYPE as the bridge is the
      largest user of options. The current stats design allows us to add
      these without any changes to the fast-path, it all comes down to
      the per-vlan stats pointer which, if this option is enabled, will
      be allocated for each port vlan instead of using the global bridge-wide
      one.
      
      CC: bridge@lists.linux-foundation.org
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      Signed-off-by: NNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9163a0fc
  23. 27 9月, 2018 6 次提交