1. 15 Oct, 2015 1 commit
  2. 13 Oct, 2015 1 commit
  3. 02 Oct, 2015 1 commit
  4. 20 Jul, 2015 1 commit
  5. 24 Jun, 2015 1 commit
  6. 14 Mar, 2015 1 commit
  7. 19 Jan, 2015 1 commit
    • Florian Fainelli's avatar
      net: bridge: reject DSA-enabled master netdevices as bridge members · 8db0a2ee
      Florian Fainelli authored
      DSA-enabled master network devices with a switch tagging protocol should
      strip the protocol specific format before handing the frame over to
      higher layer.
      When adding such a DSA master network device as a bridge member, we go
      through the following code path when receiving a frame:
      	-> first ptype check against ptype_all is not returning any
      	   handler for this skb
      	-> check and invoke rx_handler:
      		-> deliver frame to the bridge layer: br_handle_frame
      DSA registers a ptype handler with the fake ETH_XDSA ethertype, which is
      called *after* the bridge-layer rx_handler has run. br_handle_frame()
      tries to parse the frame it received from the DSA master network device,
      and will not be able to match any of its conditions and jumps straight
      at the end of the end of br_handle_frame() and returns
      Since we returned RX_HANDLER_CONSUMED, __netif_receive_skb_core() stops
      RX processing for this frame and returns NET_RX_SUCCESS, so we never get
      a chance to call our switch tag packet processing logic and deliver
      frames to the DSA slave network devices, and so we do not get any
      functional bridge members at all.
      Instead of cluttering the bridge receive path with DSA-specific checks,
      and rely on assumptions about how __netif_receive_skb_core() is
      processing frames, we simply deny adding the DSA master network device
      (conduit interface) as a bridge member, leaving only the slave DSA
      network devices to be bridge members, since those will work correctly in
      all circumstances.
      Signed-off-by: Florian Fainelli's avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 12 Jan, 2015 1 commit
  9. 06 Oct, 2014 1 commit
    • Vlad Yasevich's avatar
      bridge: Add filtering support for default_pvid · 5be5a2df
      Vlad Yasevich authored
      Currently when vlan filtering is turned on on the bridge, the bridge
      will drop all traffic untill the user configures the filter.  This
      isn't very nice for ports that don't care about vlans and just
      want untagged traffic.
      A concept of a default_pvid was recently introduced.  This patch
      adds filtering support for default_pvid.   Now, ports that don't
      care about vlans and don't define there own filter will belong
      to the VLAN of the default_pvid and continue to receive untagged
      This filtering can be disabled by setting default_pvid to 0.
      Signed-off-by: default avatarVladislav Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  10. 02 Oct, 2014 1 commit
  11. 09 Sep, 2014 1 commit
    • Jiri Pirko's avatar
      bridge: switch order of rx_handler reg and upper dev link · 0f49579a
      Jiri Pirko authored
      The thing is that netdev_master_upper_dev_link calls
      call_netdevice_notifiers(NETDEV_CHANGEUPPER, dev). That generates rtnl
      link message and during that, rtnl_link_ops->fill_slave_info is called.
      But with current ordering, rx_handler and IFF_BRIDGE_PORT are not set
      yet so there would have to be check for that in fill_slave_info callback.
      Resolve this by reordering to similar what bonding and team does to
      avoid the check.
      Also add removal of IFF_BRIDGE_PORT flag into error path.
      Signed-off-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  12. 15 Jul, 2014 1 commit
    • Tom Gundersen's avatar
      net: set name_assign_type in alloc_netdev() · c835a677
      Tom Gundersen authored
      Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert
      all users to pass NET_NAME_UNKNOWN.
      Coccinelle patch:
      expression sizeof_priv, name, setup, txqs, rxqs, count;
      -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs)
      +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs)
      -alloc_netdev_mq(sizeof_priv, name, setup, count)
      +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count)
      -alloc_netdev(sizeof_priv, name, setup)
      +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup)
      v9: move comments here from the wrong commit
      Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: default avatarDavid Herrmann <dh.herrmann@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  13. 05 Jun, 2014 1 commit
  14. 02 Jun, 2014 1 commit
  15. 19 May, 2014 1 commit
  16. 16 May, 2014 3 commits
    • Vlad Yasevich's avatar
      bridge: Automatically manage port promiscuous mode. · 2796d0c6
      Vlad Yasevich authored
      There exist configurations where the administrator or another management
      entity has the foreknowledge of all the mac addresses of end systems
      that are being bridged together.
      In these environments, the administrator can statically configure known
      addresses in the bridge FDB and disable flooding and learning on ports.
      This makes it possible to turn off promiscuous mode on the interfaces
      connected to the bridge.
      Here is why disabling flooding and learning allows us to control
       Consider port X.  All traffic coming into this port from outside the
      bridge (ingress) will be either forwarded through other ports of the
      bridge (egress) or dropped.  Forwarding (egress) is defined by FDB
      entries and by flooding in the event that no FDB entry exists.
      In the event that flooding is disabled, only FDB entries define
      the egress.  Once learning is disabled, only static FDB entries
      provided by a management entity define the egress.  If we provide
      information from these static FDBs to the ingress port X, then we'll
      be able to accept all traffic that can be successfully forwarded and
      drop all the other traffic sooner without spending CPU cycles to
      process it.
       Another way to define the above is as following equations:
          ingress = egress + drop
       expanding egress
          ingress = static FDB + learned FDB + flooding + drop
       disabling flooding and learning we a left with
          ingress = static FDB + drop
      By adding addresses from the static FDB entries to the MAC address
      filter of an ingress port X, we fully define what the bridge can
      process without dropping and can thus turn off promiscuous mode,
      thus dropping packets sooner.
      There have been suggestions that we may want to allow learning
      and update the filters with learned addresses as well.  This
      would require mac-level authentication similar to 802.1x to
      prevent attacks against the hw filters as they are limited
      Additionally, if the user places the bridge device in promiscuous mode,
      all ports are placed in promiscuous mode regardless of the changes
      to flooding and learning.
      Since the above functionality depends on full static configuration,
      we have also require that vlan filtering be enabled to take
      advantage of this.  The reason is that the bridge has to be
      able to receive and process VLAN-tagged frames and the there
      are only 2 ways to accomplish this right now: promiscuous mode
      or vlan filtering.
      Suggested-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Vlad Yasevich's avatar
      bridge: Introduce BR_PROMISC flag · f3a6ddf1
      Vlad Yasevich authored
      Introduce a BR_PROMISC per-port flag that will help us track if the
      current port is supposed to be in promiscuous mode or not.  For now,
      always start in promiscuous mode.
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Vlad Yasevich's avatar
      bridge: Keep track of ports capable of automatic discovery. · e028e4b8
      Vlad Yasevich authored
      By default, ports on the bridge are capable of automatic
      discovery of nodes located behind the port.  This is accomplished
      via flooding of unknown traffic (BR_FLOOD) and learning the
      mac addresses from these packets (BR_LEARNING).
      If the above functionality is disabled by turning off these
      flags, the port requires static configuration in the form
      of static FDB entries to function properly.
      This patch adds functionality to keep track of all ports
      capable of automatic discovery.  This will later be used
      to control promiscuity settings.
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  17. 29 Mar, 2014 1 commit
  18. 10 Feb, 2014 1 commit
    • Toshiaki Makita's avatar
      bridge: Change local fdb entries whenever mac address of bridge device changes · a4b816d8
      Toshiaki Makita authored
      Vlan code may need fdb change when changing mac address of bridge device
      even if it is caused by the mac address changing of a bridge port.
      Example configuration:
        ip link set eth0 address 12:34:56:78:90:ab
        ip link set eth1 address aa:bb:cc:dd:ee:ff
        brctl addif br0 eth0
        brctl addif br0 eth1 # br0 will have mac address 12:34:56:78:90:ab
        bridge vlan add dev br0 vid 10 self
        bridge vlan add dev eth0 vid 10
      We will have fdb entry such that f->dst == NULL, f->vlan_id == 10 and
      f->addr == 12:34:56:78:90:ab at this time.
      Next, change the mac address of eth0 to greater value.
        ip link set eth0 address ee:ff:12:34:56:78
      Then, mac address of br0 will be recalculated and set to aa:bb:cc:dd:ee:ff.
      However, an entry aa:bb:cc:dd:ee:ff will not be created and we will be not
      able to communicate using br0 on vlan 10.
      Address this issue by deleting and adding local entries whenever
      changing the mac address of the bridge device.
      If there already exists an entry that has the same address, for example,
      in case that br_fdb_changeaddr() has already inserted it,
      br_fdb_change_mac_address() will simply fail to insert it and no
      duplicated entry will be made, as it was.
      This approach also needs br_add_if() to call br_fdb_insert() before
      br_stp_recalculate_bridge_id() so that we don't create an entry whose
      dst == NULL in this function to preserve previous behavior.
      Note that this is a slight change in behavior where the bridge device can
      receive the traffic to the new address before calling
      br_stp_recalculate_bridge_id() in br_add_if().
      However, it is not a problem because we have already the address on the
      new port and such a way to insert new one before recalculating bridge id
      is taken in br_device_event() as well.
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: default avatarVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  19. 14 Jan, 2014 1 commit
  20. 18 Dec, 2013 1 commit
  21. 20 Nov, 2013 1 commit
    • Ding Tianhong's avatar
      bridge: flush br's address entry in fdb when remove the · f8730420
      Ding Tianhong authored
       bridge dev
      When the following commands are executed:
      brctl addbr br0
      ifconfig br0 hw ether <addr>
      rmmod bridge
      The calltrace will occur:
      [  563.312114] device eth1 left promiscuous mode
      [  563.312188] br0: port 1(eth1) entered disabled state
      [  563.468190] kmem_cache_destroy bridge_fdb_cache: Slab cache still has objects
      [  563.468197] CPU: 6 PID: 6982 Comm: rmmod Tainted: G           O 3.12.0-0.7-default+ #9
      [  563.468199] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [  563.468200]  0000000000000880 ffff88010f111e98 ffffffff814d1c92 ffff88010f111eb8
      [  563.468204]  ffffffff81148efd ffff88010f111eb8 0000000000000000 ffff88010f111ec8
      [  563.468206]  ffffffffa062a270 ffff88010f111ed8 ffffffffa063ac76 ffff88010f111f78
      [  563.468209] Call Trace:
      [  563.468218]  [<ffffffff814d1c92>] dump_stack+0x6a/0x78
      [  563.468234]  [<ffffffff81148efd>] kmem_cache_destroy+0xfd/0x100
      [  563.468242]  [<ffffffffa062a270>] br_fdb_fini+0x10/0x20 [bridge]
      [  563.468247]  [<ffffffffa063ac76>] br_deinit+0x4e/0x50 [bridge]
      [  563.468254]  [<ffffffff810c7dc9>] SyS_delete_module+0x199/0x2b0
      [  563.468259]  [<ffffffff814e0922>] system_call_fastpath+0x16/0x1b
      [  570.377958] Bridge firewalling registered
      --------------------------- cut here -------------------------------
      The reason is that when the bridge dev's address is changed, the
      br_fdb_change_mac_address() will add new address in fdb, but when
      the bridge was removed, the address entry in the fdb did not free,
      the bridge_fdb_cache still has objects when destroy the cache, Fix
      this by flushing the bridge address entry when removing the bridge.
      v2: according to the Toshiaki Makita and Vlad's suggestion, I only
          delete the vlan0 entry, it still have a leak here if the vlan id
          is other number, so I need to call fdb_delete_by_port(br, NULL, 1)
          to flush all entries whose dst is NULL for the bridge.
      Suggested-by: default avatarToshiaki Makita <toshiaki.makita1@gmail.com>
      Suggested-by: default avatarVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  22. 14 Nov, 2013 1 commit
    • Toshiaki Makita's avatar
      bridge: Fix memory leak when deleting bridge with vlan filtering enabled · b4e09b29
      Toshiaki Makita authored
      We currently don't call br_vlan_flush() when deleting a bridge, which
      leads to memory leak if br->vlan_info is allocated.
      Steps to reproduce:
        while :
          brctl addbr br0
          bridge vlan add dev br0 vid 10 self
          brctl delbr br0
      We can observe the cache size of corresponding slab entry
      (as kmalloc-2048 in SLUB) is increased.
      kmemleak output:
      unreferenced object 0xffff8800b68a7000 (size 2048):
        comm "bridge", pid 2086, jiffies 4295774704 (age 47.656s)
        hex dump (first 32 bytes):
          00 00 00 00 00 00 00 00 00 48 9b 36 00 88 ff ff  .........H.6....
          00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
          [<ffffffff815eb6ae>] kmemleak_alloc+0x4e/0xb0
          [<ffffffff8116a1ca>] kmem_cache_alloc_trace+0xca/0x220
          [<ffffffffa03eddd6>] br_vlan_add+0x66/0xe0 [bridge]
          [<ffffffffa03e543c>] br_setlink+0x2dc/0x340 [bridge]
          [<ffffffff8150e481>] rtnl_bridge_setlink+0x101/0x200
          [<ffffffff8150d9d9>] rtnetlink_rcv_msg+0x99/0x260
          [<ffffffff81528679>] netlink_rcv_skb+0xa9/0xc0
          [<ffffffff8150d938>] rtnetlink_rcv+0x28/0x30
          [<ffffffff81527ccd>] netlink_unicast+0xdd/0x190
          [<ffffffff8152807f>] netlink_sendmsg+0x2ff/0x740
          [<ffffffff814e8368>] sock_sendmsg+0x88/0xc0
          [<ffffffff814e8ac8>] ___sys_sendmsg.part.14+0x298/0x2b0
          [<ffffffff814e91de>] __sys_sendmsg+0x4e/0x90
          [<ffffffff814e922e>] SyS_sendmsg+0xe/0x10
          [<ffffffff81601669>] system_call_fastpath+0x16/0x1b
          [<ffffffffffffffff>] 0xffffffffffffffff
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  23. 29 Aug, 2013 1 commit
  24. 26 Jul, 2013 1 commit
  25. 11 Jun, 2013 2 commits
  26. 15 Apr, 2013 1 commit
  27. 02 Apr, 2013 1 commit
  28. 14 Feb, 2013 3 commits
  29. 04 Jan, 2013 1 commit
  30. 30 Dec, 2012 1 commit
  31. 21 Dec, 2012 1 commit
  32. 14 Aug, 2012 2 commits
  33. 27 Jun, 2012 1 commit
  34. 16 Nov, 2011 1 commit