1. 25 7月, 2010 1 次提交
    • G
      bonding: set device in RLB ARP packet handler · d8190dff
      Greg Edwards 提交于
      After:
      
      commit 6146b1a4
      Author: Jay Vosburgh <fubar@us.ibm.com>
      Date:   Tue Nov 4 17:51:15 2008 -0800
      
          bonding: Fix ALB mode to balance traffic on VLANs
      
      the dev field in the RLB ARP packet handler was set to NULL to wildcard
      and accommodate balancing VLANs on top of bonds.
      
      This has the side-effect of the packet handler being called against
      other, non RLB-enabled bonds, and a kernel oops results when it tries to
      dereference rx_hashtbl in rlb_update_entry_from_arp(), which won't be
      set for those bonds, e.g. active-backup.
      
      With the __netif_receive_skb() changes from:
      
      commit 1f3c8804
      Author: Andy Gospodarek <andy@greyhouse.net>
      Date:   Mon Dec 14 10:48:58 2009 +0000
      
          bonding: allow arp_ip_targets on separate vlans to use arp validation
      
      frames received on VLANs correctly make their way to the bond's handler,
      so we no longer need to wildcard the device.
      
      The oops can be reproduced by:
      
      modprobe bonding
      
      echo active-backup > /sys/class/net/bond0/bonding/mode
      echo 100 > /sys/class/net/bond0/bonding/miimon
      ifconfig bond0 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
      echo +eth0 > /sys/class/net/bond0/bonding/slaves
      echo +eth1 > /sys/class/net/bond0/bonding/slaves
      
      echo +bond1 > /sys/class/net/bonding_masters
      echo balance-alb > /sys/class/net/bond1/bonding/mode
      echo 100 > /sys/class/net/bond1/bonding/miimon
      ifconfig bond1 xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
      echo +eth2 > /sys/class/net/bond1/bonding/slaves
      echo +eth3 > /sys/class/net/bond1/bonding/slaves
      
      Pass some traffic on bond0.  Boom.
      
      [ Tested, behaves as advertised.  I do not believe a test of the bonding
      mode is necessary, as there is no race between the packet handler and
      the bonding mode changing (the mode can only change when the device is
      closed).  Also updated the log message to include the reproduction and
      full commit ids.  -J ]
      Signed-off-by: NGreg Edwards <greg.edwards@hp.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Acked-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8190dff
  2. 23 7月, 2010 1 次提交
    • J
      bonding: change test for presence of VLANs · f35188fa
      Jay Vosburgh 提交于
      After commit ad1afb00
      ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
      it is now regular practice for a VLAN "add vid" for VLAN 0 to
      arrive prior to any VLAN registration or creation of a vlan_group.
      
      	This patch updates the bonding code that tests for the presence
      of VLANs configured above bonding.  The new logic tests for bond->vlgrp
      to determine if a registration has occured, instead of testing that
      bonding's internal vlan_list is empty.
      
      	The old code would panic when vlan_list was not empty, but
      vlgrp was still NULL (because only an "add vid" for VLAN 0 had occured).
      
      	Bonding still adds VLAN 0 to its internal list so that 802.1p
      frames are handled correctly on transmit when non-VLAN accelerated
      slaves are members of the bond.  The test against bond->vlan_list
      remains in bond_dev_queue_xmit for this reason.
      
      	Modification to the bond->vlgrp now occurs under lock (in
      addition to RTNL), because not all inspections of it occur under RTNL.
      
      	Additionally, because 8021q will never issue a "kill vid" for
      VLAN 0, there is now logic in bond_uninit to release any remaining
      entries from vlan_list.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Cc: Pedro Garcia <pedro.netdev@dondevamos.com>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f35188fa
  3. 01 7月, 2010 1 次提交
    • F
      bonding: check if clients MAC addr has changed · 42d782ac
      Flavio Leitner 提交于
      When two systems using bonding devices in adaptive load
      balancing (ALB) communicates with each other, an endless
      ping-pong of ARP replies starts between these two systems.
      
      What happens? In the ALB mode, bonding driver keeps track
      of each client connected in a hash table, so it can do the
      receive load balancing (RLB). This hash table is updated
      when an ARP reply is received, then it scans for the client
      entry, updates its MAC address and flag it to be announced
      later. Therefore, two seconds later, the alb monitor runs
      and send for each updated client entry two ARP replies
      updating this specific client. The same process happens on
      the receiving system, causing the endless ping-pong of arp
      replies.
      
      See more information including the relevant functions below:
      
         System 1                          System 2
          bond0                             bond0
      
         ping <system2>
          ARP request  --------->
                                 <--------- ARP reply
      
      +->rlb_arp_recv  <---------------------+   <--- loop begins
      |  rlb_update_entry_from_arp           |
      |  client_info->ntt = 1;               |
      |  bond_info->rx_ntt = 1;              |
      |                                      |
      |         <communication succeed>      |
      |                                      |
      |  bond_alb_monitor                    |
      |  rlb_update_rx_clients               |
      |  rlb_update_client                   |
      |  arp_create(ARPOP_REPLY)             |
      |   send ARP reply -------------->     V
      |   send ARP reply -------------->
      |                               rlb_arp_recv
      |                               rlb_update_entry_from_arp
      |                               client_info->ntt = 1;
      |                               bond_info->rx_ntt = 1;
      |                           < snipped, same as in system 1>
      +-------           <-------------- send ARP reply
                         <-------------- send ARP reply
      
      Besides the unneeded networking traffic, this loop breaks
      a cluster because a backup system can't take over the IP
      address. There is always one system sending an ARP reply
      poisoning the network.
      
      This patch fixes the problem adding a check for the MAC
      address before updating it. Thus, if the MAC address didn't
      change, there is no need to update neither to announce it later.
      Signed-off-by: NFlavio Leitner <fleitner@redhat.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42d782ac
  4. 02 6月, 2010 1 次提交
  5. 14 12月, 2009 1 次提交
  6. 04 12月, 2009 1 次提交
  7. 31 10月, 2009 1 次提交
  8. 02 9月, 2009 1 次提交
  9. 14 8月, 2009 1 次提交
  10. 06 7月, 2009 1 次提交
  11. 05 5月, 2009 1 次提交
  12. 15 4月, 2009 1 次提交
  13. 18 2月, 2009 1 次提交
    • H
      drivers/net/bonding: fix sparse warnings: context imbalance · 1f78d9f9
      Hannes Eder 提交于
      Impact: Attribute functions with __acquires(...) and/or __releases(...).
      
      Fix this sparse warnings:
        drivers/net/bonding/bond_alb.c:1675:9: warning: context imbalance in 'bond_alb_handle_active_change' - unexpected unlock
        drivers/net/bonding/bond_alb.c:1742:9: warning: context imbalance in 'bond_alb_set_mac_address' - unexpected unlock
        drivers/net/bonding/bond_main.c:1025:17: warning: context imbalance in 'bond_do_fail_over_mac' - unexpected unlock
        drivers/net/bonding/bond_main.c:3195:13: warning: context imbalance in 'bond_info_seq_start' - wrong count at exit
        drivers/net/bonding/bond_main.c:3234:13: warning: context imbalance in 'bond_info_seq_stop' - unexpected unlock
      Signed-off-by: NHannes Eder <hannes@hanneseder.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f78d9f9
  14. 01 2月, 2009 1 次提交
  15. 10 12月, 2008 1 次提交
  16. 20 11月, 2008 1 次提交
  17. 13 11月, 2008 1 次提交
    • W
      netdevice: safe convert to netdev_priv() #part-1 · 454d7c9b
      Wang Chen 提交于
      We have some reasons to kill netdev->priv:
      1. netdev->priv is equal to netdev_priv().
      2. netdev_priv() wraps the calculation of netdev->priv's offset, obviously
         netdev_priv() is more flexible than netdev->priv.
      But we cann't kill netdev->priv, because so many drivers reference to it
      directly.
      
      This patch is a safe convert for netdev->priv to netdev_priv(netdev).
      Since all of the netdev->priv is only for read.
      But it is too big to be sent in one mail.
      I split it to 4 parts and make every part smaller than 100,000 bytes,
      which is max size allowed by vger.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      454d7c9b
  18. 06 11月, 2008 1 次提交
    • J
      bonding: Fix ALB mode to balance traffic on VLANs · 6146b1a4
      Jay Vosburgh 提交于
      	The current ALB function that processes incoming ARPs
      does not handle traffic for VLANs configured above bonding.  This causes
      traffic on those VLANs to all be assigned the same slave.  This patch
      corrects that misbehavior by locating the bonding interface nested below
      the VLAN interface.
      
      	Bug reported by Sven Anders <anders@anduras.de>, who also
      tested an earlier version of this patch and confirmed that it resolved
      the problem.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      6146b1a4
  19. 31 10月, 2008 1 次提交
    • A
      bonding: fix panic when taking bond interface down before removing module · ce39a800
      Andy Gospodarek 提交于
      A panic was discovered with bonding when using mode 5 or 6 and trying to
      remove the slaves from the bond after the interface was taken down.
      When calling 'ifconfig bond0 down' the following happens:
      
          bond_close()
              bond_alb_deinitialize()
                  tlb_deinitialize()
      		kfree(bond_info->tx_hashtbl)
                      bond_info->tx_hashtbl = NULL
      
      Unfortunately if there are still slaves in the bond, when removing the
      module the following happens:
      
          bonding_exit()
              bond_free_all()
                  bond_release_all()
                      bond_alb_deinit_slave()
                          tlb_clear_slave()
                              tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
      			u32 next_index = tx_hash_table[index].next
      
      As you might guess we panic when trying to access a few entries into the
      table that no longer exists.
      
      I experimented with several options (like moving the calls to
      tlb_deinitialize somewhere else), but it really makes the most sense to
      be part of the bond_close routine.  It also didn't seem logical move
      tlb_clear_slave around too much, so the simplest option seems to add a
      check in tlb_clear_slave to make sure we haven't already wiped the
      tx_hashtbl away before searching for all the non-existent hash-table
      entries that used to point to the slave as the output interface.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      ce39a800
  20. 25 9月, 2008 1 次提交
  21. 03 9月, 2008 1 次提交
  22. 15 7月, 2008 1 次提交
    • W
      bonding: Check return of dev_set_promiscuity/allmulti · 7e1a1ac1
      Wang Chen 提交于
      dev_set_promiscuity/allmulti might overflow.
      Commit: "netdevice: Fix promiscuity and allmulti overflow" in net-next makes
      dev_set_promiscuity/allmulti return error number if overflow happened.
      
      In bond_alb and bond_main, we check all positive increment for promiscuity
      and allmulti to get error return.
      But there are still two problems left.
      1. Some code path has no mechanism to signal errors upstream.
      2. If there are multi slaves, it's hard to tell which slaves increment
         promisc/allmulti successfully and which failed.
      So I left these problems to be FIXME.
      Fortunately, the overflow is very rare case.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e1a1ac1
  23. 26 3月, 2008 2 次提交
  24. 19 1月, 2008 2 次提交
  25. 24 10月, 2007 4 次提交
  26. 11 10月, 2007 2 次提交
  27. 26 4月, 2007 7 次提交
  28. 09 2月, 2007 1 次提交