1. 14 12月, 2013 3 次提交
    • D
      bonding: rebuild the lock use for bond_loadbalance_arp_mon() · 2e52f4fe
      dingtianhong 提交于
      The bond_loadbalance_arp_mon() use the bond lock to protect the
      bond slave list, it is no effect, so I could use RTNL or RCU to
      replace it, considering the performance impact, the RCU is more
      better here, so the bond lock replace with the RCU.
      
      The bond_select_active_slave() need RTNL and curr_slave_lock
      together, but there is no RTNL lock here, so add a rtnl_rtylock.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Suggested-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e52f4fe
    • D
      bonding: rebuild the lock use for bond_mii_monitor() · 4cb4f97b
      dingtianhong 提交于
      The bond_mii_monitor() still use bond lock to protect bond slave list,
      it is no effect, I have 2 way to fix the problem, move the RTNL to the
      top of the function, or add RCU to protect the bond slave list,
      according to the Jay Vosburgh's opinion, 10 times one second is a
      truely big performance loss if use RTNL to protect the whole monitor,
      so I would take the advice and use RCU to protect the bond slave list.
      
      The bond_has_slave() will not protect by anything, there will no things
      happen if the slave list is be changed, unless the bond was free, but
      it will not happened before the monitor, the bond will closed before
      be freed.
      
      The peers notify for the bond will calling curr_active_slave, so
      derefence the slave to make sure we will accessing the same slave
      if the curr_active_slave changed, as the rcu dereference need in
      read-side critical sector and bond_change_active_slave() will call
      it with no RCU hold,  so add peer notify in rcu_read_lock which
      will be nested in monitor.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Suggested-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cb4f97b
    • D
      bonding: remove the no effect lock for bond_select_active_slave() · b2e7aceb
      dingtianhong 提交于
      The bond slave list was no longer protected by bond lock and only
      protected by RTNL or RCU, so anywhere that use bond lock to protect
      slave list is meaningless.
      
      remove the release and acquire bond lock for bond_select_active_slave().
      
      The curr_active_slave could only be changed in 3 place:
      
      1. enslave slave.
      2. release slave.
      3. change_active_slave.
      
      all above place were holding bond lock, RTNL and curr_slave_lock
      together, it is tedious and meaningless, obviously bond lock is no
      need here, but RTNL or curr_slave_lock is needed, so if you want
      to access active slave, you have to choose one lock, RTNL or
      curr_slave_lock, if RTNL is exist, no need to add curr_slave_lock,
      otherwise curr_slave_lock is better, because of the performance.
      
      there are several place calling bond_select_active_slave() and
      bond_change_active_slave(), the next step I will clean these place
      and remove the no effect lock.
      
      there are some document changed together when update the function.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Suggested-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b2e7aceb
  2. 06 12月, 2013 1 次提交
  3. 29 11月, 2013 1 次提交
  4. 08 11月, 2013 1 次提交
  5. 28 10月, 2013 4 次提交
    • D
      Revert "Merge branch 'bonding_monitor_locking'" · 1f2cd845
      David S. Miller 提交于
      This reverts commit 4d961a10, reversing
      changes made to a00f6fcc.
      
      Revert bond locking changes, they cause regressions and Veaceslav Falico
      doesn't like how the commit messages were done at all.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f2cd845
    • D
      bonding: remove bond read lock for bond_activebackup_arp_mon() · 80b9d236
      dingtianhong 提交于
      The bond slave list may change when the monitor is running, the slave list is no longer
      protected by bond->lock, only protected by rtnl lock(), so we have 3 ways to modify it:
      1.add bond_master_upper_dev_link() and bond_upper_dev_unlink() in bond->lock, but it is unsafe
      to call call_netdevice_notifiers() in write lock.
      2.remove unused bond->lock for monitor function, only use the existing rtnl lock().
      3.use rcu_read_lock() to protect it, of course, it will transform bond_for_each_slave to
      bond_for_each_slave_rcu() and performance is better, but in slow path, it is ignored.
      so I remove the bond->lock and move the rtnl lock to protect the whole monitor function.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80b9d236
    • D
      bonding: remove bond read lock for bond_loadbalance_arp_mon() · 7f1bb571
      dingtianhong 提交于
      The bond slave list may change when the monitor is running, the slave list is no longer
      protected by bond->lock, only protected by rtnl lock(), so we have 3 ways to modify it:
      1.add bond_master_upper_dev_link() and bond_upper_dev_unlink() in bond->lock, but it is unsafe
      to call call_netdevice_notifiers() in write lock.
      2.remove unused bond->lock for monitor function, only use the existing rtnl lock().
      3.use rcu_read_lock() to protect it, of course, it will transform bond_for_each_slave to
      bond_for_each_slave_rcu() and performance is better, but in slow path, it is ignored.
      so I remove the bond->lock and add the rtnl lock to protect the whole monitor function.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f1bb571
    • D
      bonding: remove bond read lock for bond_mii_monitor() · 6b6c5261
      dingtianhong 提交于
      The bond slave list may change when the monitor is running, the slave list is no longer
      protected by bond->lock, only protected by rtnl lock(), so we have 3 ways to modify it:
      1.add bond_master_upper_dev_link() and bond_upper_dev_unlink() in bond->lock, but it is unsafe
      to call call_netdevice_notifiers() in write lock.
      2.remove unused bond->lock for monitor function, only use the existing rtnl lock().
      3.use rcu_read_lock() to protect it, of course, it will transform bond_for_each_slave to
      bond_for_each_slave_rcu() and performance is better, but in slow path, it is ignored.
      so I remove the bond->lock and move the rtnl lock to protect the whole monitor function.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6b6c5261
  6. 26 10月, 2013 1 次提交
    • A
      net: fix rtnl notification in atomic context · 7f294054
      Alexei Starovoitov 提交于
      commit 991fb3f7 "dev: always advertise rx_flags changes via netlink"
      introduced rtnl notification from __dev_set_promiscuity(),
      which can be called in atomic context.
      
      Steps to reproduce:
      ip tuntap add dev tap1 mode tap
      ifconfig tap1 up
      tcpdump -nei tap1 &
      ip tuntap del dev tap1 mode tap
      
      [  271.627994] device tap1 left promiscuous mode
      [  271.639897] BUG: sleeping function called from invalid context at mm/slub.c:940
      [  271.664491] in_atomic(): 1, irqs_disabled(): 0, pid: 3394, name: ip
      [  271.677525] INFO: lockdep is turned off.
      [  271.690503] CPU: 0 PID: 3394 Comm: ip Tainted: G        W    3.12.0-rc3+ #73
      [  271.703996] Hardware name: System manufacturer System Product Name/P8Z77 WS, BIOS 3007 07/26/2012
      [  271.731254]  ffffffff81a58506 ffff8807f0d57a58 ffffffff817544e5 ffff88082fa0f428
      [  271.760261]  ffff8808071f5f40 ffff8807f0d57a88 ffffffff8108bad1 ffffffff81110ff8
      [  271.790683]  0000000000000010 00000000000000d0 00000000000000d0 ffff8807f0d57af8
      [  271.822332] Call Trace:
      [  271.838234]  [<ffffffff817544e5>] dump_stack+0x55/0x76
      [  271.854446]  [<ffffffff8108bad1>] __might_sleep+0x181/0x240
      [  271.870836]  [<ffffffff81110ff8>] ? rcu_irq_exit+0x68/0xb0
      [  271.887076]  [<ffffffff811a80be>] kmem_cache_alloc_node+0x4e/0x2a0
      [  271.903368]  [<ffffffff810b4ddc>] ? vprintk_emit+0x1dc/0x5a0
      [  271.919716]  [<ffffffff81614d67>] ? __alloc_skb+0x57/0x2a0
      [  271.936088]  [<ffffffff810b4de0>] ? vprintk_emit+0x1e0/0x5a0
      [  271.952504]  [<ffffffff81614d67>] __alloc_skb+0x57/0x2a0
      [  271.968902]  [<ffffffff8163a0b2>] rtmsg_ifinfo+0x52/0x100
      [  271.985302]  [<ffffffff8162ac6d>] __dev_notify_flags+0xad/0xc0
      [  272.001642]  [<ffffffff8162ad0c>] __dev_set_promiscuity+0x8c/0x1c0
      [  272.017917]  [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
      [  272.033961]  [<ffffffff8162b109>] dev_set_promiscuity+0x29/0x50
      [  272.049855]  [<ffffffff8172e937>] packet_dev_mc+0x87/0xc0
      [  272.065494]  [<ffffffff81732052>] packet_notifier+0x1b2/0x380
      [  272.080915]  [<ffffffff81731ea5>] ? packet_notifier+0x5/0x380
      [  272.096009]  [<ffffffff81761c66>] notifier_call_chain+0x66/0x150
      [  272.110803]  [<ffffffff8108503e>] __raw_notifier_call_chain+0xe/0x10
      [  272.125468]  [<ffffffff81085056>] raw_notifier_call_chain+0x16/0x20
      [  272.139984]  [<ffffffff81620190>] call_netdevice_notifiers_info+0x40/0x70
      [  272.154523]  [<ffffffff816201d6>] call_netdevice_notifiers+0x16/0x20
      [  272.168552]  [<ffffffff816224c5>] rollback_registered_many+0x145/0x240
      [  272.182263]  [<ffffffff81622641>] rollback_registered+0x31/0x40
      [  272.195369]  [<ffffffff816229c8>] unregister_netdevice_queue+0x58/0x90
      [  272.208230]  [<ffffffff81547ca0>] __tun_detach+0x140/0x340
      [  272.220686]  [<ffffffff81547ed6>] tun_chr_close+0x36/0x60
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f294054
  7. 23 10月, 2013 1 次提交
    • V
      bonding: move bond-specific init after enslave happens · 5378c2e6
      Veaceslav Falico 提交于
      As Jiri noted, currently we first do all bonding-specific initialization
      (specifically - bond_select_active_slave(bond)) before we actually attach
      the slave (so that it becomes visible through bond_for_each_slave() and
      friends). This might result in bond_select_active_slave() not seeing the
      first/new slave and, thus, not actually selecting an active slave.
      
      Fix this by moving all the bond-related init part after we've actually
      completely initialized and linked (via bond_master_upper_dev_link()) the
      new slave.
      
      Also, remove the bond_(de/a)ttach_slave(), it's useless to have functions
      to ++/-- one int.
      
      After this we have all the initialization of the new slave *before*
      linking, and all the stuff that needs to be done on bonding *after* it. It
      has also a bonus effect - we can remove the locking on the new slave init
      completely, and only use it for bond_select_active_slave().
      Reported-by: NJiri Pirko <jiri@resnulli.us>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Acked-by: Ding Tianhong@huawei.com
      Reviewed-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5378c2e6
  8. 20 10月, 2013 2 次提交
  9. 04 10月, 2013 1 次提交
    • N
      bonding: modify the old and add new xmit hash policies · 32819dc1
      Nikolay Aleksandrov 提交于
      This patch adds two new hash policy modes which use skb_flow_dissect:
      3 - Encapsulated layer 2+3
      4 - Encapsulated layer 3+4
      There should be a good improvement for tunnel users in those modes.
      It also changes the old hash functions to:
      hash ^= (__force u32)flow.dst ^ (__force u32)flow.src;
      hash ^= (hash >> 16);
      hash ^= (hash >> 8);
      
      Where hash will be initialized either to L2 hash, that is
      SRCMAC[5] XOR DSTMAC[5], or to flow->ports which should be extracted
      from the upper layer. Flow's dst and src are also extracted based on the
      xmit policy either directly from the buffer or by using skb_flow_dissect,
      but in both cases if the protocol is IPv6 then dst and src are obtained by
      ipv6_addr_hash() on the real addresses. In case of a non-dissectable
      packet, the algorithms fall back to L2 hashing.
      The bond_set_mode_ops() function is now obsolete and thus deleted
      because it was used only to set the proper hash policy. Also we trim a
      pointer from struct bonding because we no longer need to keep the hash
      function, now there's only a single hash function - bond_xmit_hash that
      works based on bond->params.xmit_policy.
      
      The hash function and skb_flow_dissect were suggested by Eric Dumazet.
      The layer names were suggested by Andy Gospodarek, because I suck at
      semantics.
      Signed-off-by: NNikolay Aleksandrov <nikolay@redhat.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      32819dc1
  10. 01 10月, 2013 2 次提交
    • V
      bonding: RCUify bond_set_rx_mode() · b3241870
      Veaceslav Falico 提交于
      Currently we rely on rtnl locking in bond_set_rx_mode(), however it's not
      always the case:
      
      RTNL: assertion failed at drivers/net/bonding/bond_main.c (3391)
      ...
       [<ffffffff81651ca5>] dump_stack+0x54/0x74
       [<ffffffffa029e717>] bond_set_rx_mode+0xc7/0xd0 [bonding]
       [<ffffffff81553af7>] __dev_set_rx_mode+0x57/0xa0
       [<ffffffff81557ff8>] __dev_mc_add+0x58/0x70
       [<ffffffff81558020>] dev_mc_add+0x10/0x20
       [<ffffffff8161e26e>] igmp6_group_added+0x18e/0x1d0
       [<ffffffff81186f76>] ? kmem_cache_alloc_trace+0x236/0x260
       [<ffffffff8161f80f>] ipv6_dev_mc_inc+0x29f/0x320
       [<ffffffff8161f9e7>] ipv6_sock_mc_join+0x157/0x260
      ...
      
      Fix this by using RCU primitives.
      Reported-by: NJoe Lawrence <joe.lawrence@stratus.com>
      Tested-by: NJoe Lawrence <joe.lawrence@stratus.com>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3241870
    • N
      bonding: Fix broken promiscuity reference counting issue · 5a0068de
      Neil Horman 提交于
      Recently grabbed this report:
      https://bugzilla.redhat.com/show_bug.cgi?id=1005567
      
      Of an issue in which the bonding driver, with an attached vlan encountered the
      following errors when bond0 was taken down and back up:
      
      dummy1: promiscuity touches roof, set promiscuity failed. promiscuity feature of
      device might be broken.
      
      The error occurs because, during __bond_release_one, if we release our last
      slave, we take on a random mac address and issue a NETDEV_CHANGEADDR
      notification.  With an attached vlan, the vlan may see that the vlan and bond
      mac address were in sync, but no longer are.  This triggers a call to dev_uc_add
      and dev_set_rx_mode, which enables IFF_PROMISC on the bond device.  Then, when
      we complete __bond_release_one, we use the current state of the bond flags to
      determine if we should decrement the promiscuity of the releasing slave.  But
      since the bond changed promiscuity state during the release operation, we
      incorrectly decrement the slave promisc count when it wasn't in promiscuous mode
      to begin with, causing the above error
      
      Fix is pretty simple, just cache the bonding flags at the start of the function
      and use those when determining the need to set promiscuity.
      
      This is also needed for the ALLMULTI flag
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Mark Wu <wudxw@linux.vnet.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Reported-by: NMark Wu <wudxw@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a0068de
  11. 29 9月, 2013 1 次提交
    • V
      bonding: correctly verify for the first slave in bond_enslave · 23c147e0
      Veaceslav Falico 提交于
      After commit 1f718f0f ("bonding: populate
      neighbour's private on enslave"), we've moved the actual 'linking' in the
      end of the function - so that, once linked, the slave is ready to be used,
      and is not still in the process of enslaving.
      
      However, 802.3ad verified if it's the first slave by looking at the
      
      if (bond_first_slave(bond) == new_slave)
      
      which, because we've moved the linking to the end, became broken - on the
      first slave bond_first_slave(bond) returns NULL.
      
      Fix this by verifying if the prev_slave, that equals bond_last_slave(), is
      actually populated - if it is - then it's not the first slave, and vice
      versa.
      
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      23c147e0
  12. 27 9月, 2013 11 次提交
  13. 16 9月, 2013 1 次提交
  14. 12 9月, 2013 1 次提交
  15. 04 9月, 2013 4 次提交
  16. 30 8月, 2013 5 次提交