1. 02 7月, 2010 1 次提交
  2. 01 7月, 2010 3 次提交
    • 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
    • D
      Bluetooth: Fix abuse of the preincrement operator · dd1589a4
      David Howells 提交于
      Fix abuse of the preincrement operator as detected when building with gcc
      4.6.0:
      
      	 CC [M]  drivers/bluetooth/hci_bcsp.o
      	drivers/bluetooth/hci_bcsp.c: In function 'bcsp_prepare_pkt':
      	drivers/bluetooth/hci_bcsp.c:247:20: warning: operation on 'bcsp->msgq_txseq' may be undefined
      Reported-by: NJustin P. Mattock <justinmattock@gmail.com>
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Acked-by: NGustavo F. Padovan <padovan@profusion.mobi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dd1589a4
    • S
      mv643xx_eth: use sw csum for big packets · 9b2c2ff7
      Saeed Bishara 提交于
      Some controllers (KW, Dove) limits the TX IP/layer4 checksum offloading to a max size.
      Signed-off-by: NSaeed Bishara <saeed@marvell.com>
      Acked-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b2c2ff7
  3. 30 6月, 2010 3 次提交
  4. 29 6月, 2010 1 次提交
    • A
      bonding: prevent netpoll over bonded interfaces · c22d7ac8
      Andy Gospodarek 提交于
      Support for netpoll over bonded interfaces was added here:
      
      	commit f6dc31a8
      	Author: WANG Cong <amwang@redhat.com>
      	Date:   Thu May 6 00:48:51 2010 -0700
      
      	    bonding: make bonding support netpoll
      
      but it is bad enough that we should probably just disable netpoll over
      bonding until some of the locking logic in the bonding driver is changed
      or converted completely to RCU.  Simple actions like changing the active
      slave in active-backup mode will hang the box if a high enough printk
      debugging level is enabled.
      
      Keeping the old code around will be good for anyone that wants to work
      on it (and for after the RCU conversion), so I propose this small patch
      rather than ripping it all out.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c22d7ac8
  5. 27 6月, 2010 3 次提交
  6. 26 6月, 2010 9 次提交
  7. 24 6月, 2010 4 次提交
  8. 23 6月, 2010 1 次提交
  9. 22 6月, 2010 2 次提交
  10. 19 6月, 2010 1 次提交
    • B
      ath5k: initialize ah->ah_current_channel · b6855772
      Bob Copeland 提交于
      ath5k assumes ah_current_channel is always a valid pointer in
      several places, but a newly created interface may not have a
      channel.  To avoid null pointer dereferences, set it up to point
      to the first available channel until later reconfigured.
      
      This fixes the following oops:
      $ rmmod ath5k
      $ insmod ath5k
      $ iw phy0 set distance 11000
      
      BUG: unable to handle kernel NULL pointer dereference at 00000006
      IP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      *pde = 00000000
      Oops: 0000 [#1]
      last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index
      Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90
      scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci
      8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc
      
      Pid: 1597, comm: iw Not tainted (2.6.32.14 #8)
      EIP: 0060:[<d0a1ff24>] EFLAGS: 00010296 CPU: 0
      EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k]
      EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080
      ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4
        DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000)
      Stack:
        d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0
      <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7
      <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000
      Call Trace:
        [<d0a27f0c>] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k]
        [<d09bfdc7>] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211]
        [<d08e0d28>] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211]
        [<c10f5db9>] ? nla_parse+0x59/0xc0
        [<c11ca8d9>] ? genl_rcv_msg+0x169/0x1a0
        [<c11ca770>] ? genl_rcv_msg+0x0/0x1a0
        [<c11c7e68>] ? netlink_rcv_skb+0x38/0x90
        [<c11c9649>] ? genl_rcv+0x19/0x30
        [<c11c7c03>] ? netlink_unicast+0x1b3/0x220
        [<c11c893e>] ? netlink_sendmsg+0x26e/0x290
        [<c11a409e>] ? sock_sendmsg+0xbe/0xf0
        [<c1032780>] ? autoremove_wake_function+0x0/0x50
        [<c104d846>] ? __alloc_pages_nodemask+0x106/0x530
        [<c1074933>] ? do_lookup+0x53/0x1b0
        [<c10766f9>] ? __link_path_walk+0x9b9/0x9e0
        [<c11acab0>] ? verify_iovec+0x50/0x90
        [<c11a42b1>] ? sys_sendmsg+0x1e1/0x270
        [<c1048e50>] ? find_get_page+0x10/0x50
        [<c104a96f>] ? filemap_fault+0x5f/0x370
        [<c1059159>] ? __do_fault+0x319/0x370
        [<c11a55b4>] ? sys_socketcall+0x244/0x290
        [<c101962c>] ? do_page_fault+0x1ec/0x270
        [<c1019440>] ? do_page_fault+0x0/0x270
        [<c1002ae5>] ? syscall_call+0x7/0xb
      Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24
      0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7
      43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2
      EIP: [<d0a1ff24>] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP
      0068:cfa09bf4
      CR2: 0000000000000006
      ---[ end trace 54f73d6b10ceb87b ]---
      
      Cc: stable@kernel.org
      Reported-by: NSteve Brown <sbrown@cortland.com>
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b6855772
  11. 17 6月, 2010 8 次提交
  12. 16 6月, 2010 4 次提交