1. 17 5月, 2014 2 次提交
  2. 30 3月, 2014 1 次提交
  3. 11 2月, 2014 1 次提交
    • T
      bridge: Change local fdb entries whenever mac address of bridge device changes · a4b816d8
      Toshiaki Makita 提交于
      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: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: NVlad Yasevich <vyasevic@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b816d8
  4. 14 1月, 2014 1 次提交
  5. 19 12月, 2013 1 次提交
  6. 21 11月, 2013 1 次提交
    • D
      bridge: flush br's address entry in fdb when remove the · f8730420
      Ding Tianhong 提交于
       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: NToshiaki Makita <toshiaki.makita1@gmail.com>
      Suggested-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8730420
  7. 15 11月, 2013 1 次提交
    • T
      bridge: Fix memory leak when deleting bridge with vlan filtering enabled · b4e09b29
      Toshiaki Makita 提交于
      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 :
        do
          brctl addbr br0
          bridge vlan add dev br0 vid 10 self
          brctl delbr br0
        done
      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  ................
        backtrace:
          [<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: NToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4e09b29
  8. 30 8月, 2013 1 次提交
  9. 27 7月, 2013 1 次提交
  10. 11 6月, 2013 2 次提交
  11. 16 4月, 2013 1 次提交
  12. 03 4月, 2013 1 次提交
  13. 14 2月, 2013 3 次提交
  14. 05 1月, 2013 1 次提交
  15. 30 12月, 2012 1 次提交
  16. 22 12月, 2012 1 次提交
  17. 15 8月, 2012 2 次提交
  18. 27 6月, 2012 1 次提交
  19. 17 11月, 2011 1 次提交
  20. 19 10月, 2011 1 次提交
  21. 04 10月, 2011 1 次提交
  22. 16 9月, 2011 2 次提交
    • J
      net: consolidate and fix ethtool_ops->get_settings calling · 4bc71cb9
      Jiri Pirko 提交于
      This patch does several things:
      - introduces __ethtool_get_settings which is called from ethtool code and
        from drivers as well. Put ASSERT_RTNL there.
      - dev_ethtool_get_settings() is replaced by __ethtool_get_settings()
      - changes calling in drivers so rtnl locking is respected. In
        iboe_get_rate was previously ->get_settings() called unlocked. This
        fixes it. Also prb_calc_retire_blk_tmo() in af_packet.c had the same
        problem. Also fixed by calling __dev_get_by_index() instead of
        dev_get_by_index() and holding rtnl_lock for both calls.
      - introduces rtnl_lock in bnx2fc_vport_create() and fcoe_vport_create()
        so bnx2fc_if_create() and fcoe_if_create() are called locked as they
        are from other places.
      - use __ethtool_get_settings() in bonding code
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      
      v2->v3:
      	-removed dev_ethtool_get_settings()
      	-added ASSERT_RTNL into __ethtool_get_settings()
      	-prb_calc_retire_blk_tmo - use __dev_get_by_index() and lock
      	 around it and __ethtool_get_settings() call
      v1->v2:
              add missing export_symbol
      Reviewed-by: Ben Hutchings <bhutchings@solarflare.com> [except FCoE bits]
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bc71cb9
    • J
      br: remove redundant check and init · fa3df928
      Jiri Pirko 提交于
      Since these checks and initialization are done in
      dev_ethtool_get_settings called later on, remove this redundancy.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa3df928
  23. 23 8月, 2011 1 次提交
  24. 10 8月, 2011 1 次提交
  25. 23 7月, 2011 1 次提交
  26. 23 5月, 2011 2 次提交
  27. 30 4月, 2011 1 次提交
  28. 29 4月, 2011 1 次提交
  29. 05 4月, 2011 1 次提交
    • S
      bridge: allow creating bridge devices with netlink · bb900b27
      stephen hemminger 提交于
      Add netlink device ops to allow creating bridge device via netlink.
      This works in a manner similar to vlan, macvlan and bonding.
      
      Example:
        # ip link add link dev br0 type bridge
        # ip link del dev br0
      
      The change required rearranging initializtion code to deal with
      being called by create link. Most of the initialization happens
      in br_dev_setup, but allocation of stats is done in ndo_init callback
      to deal with allocation failure. Sysfs setup has to wait until
      after the network device kobject is registered.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb900b27
  30. 28 3月, 2011 1 次提交
  31. 14 2月, 2011 1 次提交
  32. 25 1月, 2011 2 次提交