1. 30 10月, 2011 1 次提交
    • J
      bonding: eliminate bond_close race conditions · e6d265e8
      Jay Vosburgh 提交于
      This patch resolves two sets of race conditions.
      
      	Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com> reported the
      first, as follows:
      
      The bond_close() calls cancel_delayed_work() to cancel delayed works.
      It, however, cannot cancel works that were already queued in workqueue.
      The bond_open() initializes work->data, and proccess_one_work() refers
      get_work_cwq(work)->wq->flags. The get_work_cwq() returns NULL when
      work->data has been initialized. Thus, a panic occurs.
      
      	He included a patch that converted the cancel_delayed_work calls
      in bond_close to flush_delayed_work_sync, which eliminated the above
      problem.
      
      	His patch is incorporated, at least in principle, into this
      patch.  In this patch, we use cancel_delayed_work_sync in place of
      flush_delayed_work_sync, and also convert bond_uninit in addition to
      bond_close.
      
      	This conversion to _sync, however, opens new races between
      bond_close and three periodically executing workqueue functions:
      bond_mii_monitor, bond_alb_monitor and bond_activebackup_arp_mon.
      
      	The race occurs because bond_close and bond_uninit are always
      called with RTNL held, and these workqueue functions may acquire RTNL to
      perform failover-related activities.  If bond_close or bond_uninit is
      waiting in cancel_delayed_work_sync, deadlock occurs.
      
      	These deadlocks are resolved by having the workqueue functions
      acquire RTNL conditionally.  If the rtnl_trylock() fails, the functions
      reschedule and return immediately.  For the cases that are attempting to
      perform link failover, a delay of 1 is used; for the other cases, the
      normal interval is used (as those activities are not as time critical).
      
      	Additionally, the bond_mii_monitor function now stores the delay
      in a variable (mimicing the structure of activebackup_arp_mon).
      
      	Lastly, all of the above renders the kill_timers sentinel moot,
      and therefore it has been removed.
      Tested-by: NMitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e6d265e8
  2. 20 10月, 2011 1 次提交
    • F
      bonding: fix wrong port enabling in 802.3ad · d5edf290
      Flavio Leitner 提交于
      The port shouldn't be enabled unless its current MUX
      state is DISTRIBUTING which is correctly handled by
      ad_mux_machine(), otherwise the packet sent can be
      lost because the other end may not be ready.
      
      The issue happens on every port initialization, but
      as the ports are expected to move quickly to DISTRIBUTING,
      it doesn't cause much problem.  However, it does cause
      constant packet loss if the other peer has the port
      configured to stay in STANDBY (i.e. SYNC set to OFF).
      Signed-off-by: NFlavio Leitner <fbl@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5edf290
  3. 04 10月, 2011 1 次提交
    • A
      bonding: properly stop queuing work when requested · a0db2dad
      Andy Gospodarek 提交于
      During a test where a pair of bonding interfaces using ARP monitoring
      were both brought up and torn down (with an rmmod) repeatedly, a panic
      in the timer code was noticed.  I tracked this down and determined that
      any of the bonding functions that ran as workqueue handlers and requeued
      more work might not properly exit when the module was removed.
      
      There was a flag protected by the bond lock called kill_timers that is
      set when the interface goes down or the module is removed, but many of
      the functions that monitor link status now unlock the bond lock to take
      rtnl first.  There is a chance that another CPU running the rmmod could
      get the lock and set kill_timers after the first check has passed.
      
      This patch does not allow any function to queue work that will make
      itself run unless kill_timers is not set.  I also noticed while doing
      this work that bond_resend_igmp_join_requests did not have a check for
      kill_timers, so I added the needed call there as well.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Reported-by: NLiang Zheng <lzheng@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0db2dad
  4. 23 6月, 2011 1 次提交
  5. 14 6月, 2011 1 次提交
  6. 10 6月, 2011 3 次提交
  7. 10 5月, 2011 1 次提交
  8. 26 4月, 2011 1 次提交
    • J
      bonding: move processing of recv handlers into handle_frame() · 3aba891d
      Jiri Pirko 提交于
      Since now when bonding uses rx_handler, all traffic going into bond
      device goes thru bond_handle_frame. So there's no need to go back into
      bonding code later via ptype handlers. This patch converts
      original ptype handlers into "bonding receive probes". These functions
      are called from bond_handle_frame and they are registered per-mode.
      
      Note that vlan packets are also handled because they are always untagged
      thanks to vlan_untag()
      
      Note that this also allows arpmon for eth-bond-bridge-vlan topology.
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3aba891d
  9. 20 4月, 2011 1 次提交
    • J
      bonding: 802.3ad - fix agg_device_up · 2430af8b
      Jiri Bohac 提交于
      The slave member of struct aggregator does not necessarily point
      to a slave which is part of the aggregator. It points to the
      slave structure containing the aggregator structure, while
      completely different slaves (or no slaves at all) may be part of
      the aggregator.
      
      The agg_device_up() function wrongly uses agg->slave to find the state
      of the aggregator.  Use agg->lag_ports->slave instead. The bug has
      been introduced by commit 4cd6fe1c
      ("bonding: fix link down handling in 802.3ad mode").
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2430af8b
  10. 15 4月, 2011 1 次提交
  11. 17 3月, 2011 1 次提交
  12. 08 3月, 2011 2 次提交
  13. 21 1月, 2011 1 次提交
    • N
      bonding: Ensure that we unshare skbs prior to calling pskb_may_pull · b3053251
      Neil Horman 提交于
      Recently reported oops:
      
      kernel BUG at net/core/skbuff.c:813!
      invalid opcode: 0000 [#1] SMP
      last sysfs file: /sys/devices/virtual/net/bond0/broadcast
      CPU 8
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      
      Modules linked in: sit tunnel4 cpufreq_ondemand acpi_cpufreq freq_table bonding
      ipv6 dm_mirror dm_region_hash dm_log cdc_ether usbnet mii serio_raw i2c_i801
      i2c_core iTCO_wdt iTCO_vendor_support shpchp ioatdma i7core_edac edac_core bnx2
      ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
      scsi_transport_sas dm_mod [last unloaded: microcode]
      Pid: 0, comm: swapper Not tainted 2.6.32-71.el6.x86_64 #1 BladeCenter HS22
      -[7870AC1]-
      RIP: 0010:[<ffffffff81405b16>]  [<ffffffff81405b16>]
      pskb_expand_head+0x36/0x1e0
      RSP: 0018:ffff880028303b70  EFLAGS: 00010202
      RAX: 0000000000000002 RBX: ffff880c6458ec80 RCX: 0000000000000020
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880c6458ec80
      RBP: ffff880028303bc0 R08: ffffffff818a6180 R09: ffff880c6458ed64
      R10: ffff880c622b36c0 R11: 0000000000000400 R12: 0000000000000000
      R13: 0000000000000180 R14: ffff880c622b3000 R15: 0000000000000000
      FS:  0000000000000000(0000) GS:ffff880028300000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
      CR2: 00000038653452a4 CR3: 0000000001001000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper (pid: 0, threadinfo ffff8806649c2000, task ffff880c64f16ab0)
      Stack:
       ffff880028303bc0 ffffffff8104fff9 000000000000001c 0000000100000000
      <0> ffff880000047d80 ffff880c6458ec80 000000000000001c ffff880c6223da00
      <0> ffff880c622b3000 0000000000000000 ffff880028303c10 ffffffff81407f7a
      Call Trace:
      <IRQ>
       [<ffffffff8104fff9>] ? __wake_up_common+0x59/0x90
       [<ffffffff81407f7a>] __pskb_pull_tail+0x2aa/0x360
       [<ffffffffa0244530>] bond_arp_rcv+0x2c0/0x2e0 [bonding]
       [<ffffffff814a0857>] ? packet_rcv+0x377/0x440
       [<ffffffff8140f21b>] netif_receive_skb+0x2db/0x670
       [<ffffffff8140f788>] napi_skb_finish+0x58/0x70
       [<ffffffff8140fc89>] napi_gro_receive+0x39/0x50
       [<ffffffffa01286eb>] ixgbe_clean_rx_irq+0x35b/0x900 [ixgbe]
       [<ffffffffa01290f6>] ixgbe_clean_rxtx_many+0x136/0x240 [ixgbe]
       [<ffffffff8140fe53>] net_rx_action+0x103/0x210
       [<ffffffff81073bd7>] __do_softirq+0xb7/0x1e0
       [<ffffffff810d8740>] ? handle_IRQ_event+0x60/0x170
       [<ffffffff810142cc>] call_softirq+0x1c/0x30
       [<ffffffff81015f35>] do_softirq+0x65/0xa0
       [<ffffffff810739d5>] irq_exit+0x85/0x90
       [<ffffffff814cf915>] do_IRQ+0x75/0xf0
       [<ffffffff81013ad3>] ret_from_intr+0x0/0x11
       <EOI>
       [<ffffffff8101bc01>] ? mwait_idle+0x71/0xd0
       [<ffffffff814cd80a>] ? atomic_notifier_call_chain+0x1a/0x20
       [<ffffffff81011e96>] cpu_idle+0xb6/0x110
       [<ffffffff814c17c8>] start_secondary+0x1fc/0x23f
      
      Resulted from bonding driver registering packet handlers via dev_add_pack and
      then trying to call pskb_may_pull. If another packet handler (like for AF_PACKET
      sockets) gets called first, the delivered skb will have a user count > 1, which
      causes pskb_may_pull to BUG halt when it does its skb_shared check.  Fix this by
      calling skb_share_check prior to the may_pull call sites in the bonding driver
      to clone the skb when needed.  Tested by myself and the reported successfully.
      
      Signed-off-by: Neil Horman
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: Jay Vosburgh <fubar@us.ibm.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3053251
  14. 18 11月, 2010 1 次提交
  15. 02 11月, 2010 1 次提交
  16. 21 10月, 2010 2 次提交
  17. 27 9月, 2010 1 次提交
  18. 15 9月, 2010 1 次提交
    • A
      bonding: correctly process non-linear skbs · ab12811c
      Andy Gospodarek 提交于
      It was recently brought to my attention that 802.3ad mode bonds would no
      longer form when using some network hardware after a driver update.
      After snooping around I realized that the particular hardware was using
      page-based skbs and found that skb->data did not contain a valid LACPDU
      as it was not stored there.  That explained the inability to form an
      802.3ad-based bond.  For balance-alb mode bonds this was also an issue
      as ARPs would not be properly processed.
      
      This patch fixes the issue in my tests and should be applied to 2.6.36
      and as far back as anyone cares to add it to stable.
      
      Thanks to Alexander Duyck <alexander.h.duyck@intel.com> and Jesse
      Brandeburg <jesse.brandeburg@intel.com> for the suggestions on this one.
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      CC: Alexander Duyck <alexander.h.duyck@intel.com>
      CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      CC: stable@kerne.org
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ab12811c
  19. 27 12月, 2009 1 次提交
  20. 14 12月, 2009 1 次提交
  21. 04 12月, 2009 1 次提交
  22. 16 11月, 2009 1 次提交
    • J
      bonding: fix 802.3ad standards compliance error · 2d6682db
      Jay Vosburgh 提交于
      The language of 802.3ad 43.4.9 requires the "recordPDU" function
      to, in part, compare the Partner parameter values in a received LACPDU
      to the stored Actor values.  If those match, then the Partner's
      synchronization state is set to true.
      
      	The current 802.3ad implementation is performing these steps out
      of order; first, the synchronization check is done, then the paramters are
      checked to see if they match (the synch check being done against a match
      check of a prior LACPDU).  This causes delays in establishing aggregators
      in some circumstances.
      
      	This patch modifies the 802.3ad code to call __choose_matched,
      the function that does the "match" comparisions, as the first step of
      __record_pdu, instead of immediately afterwards.  This new behavior is
      in compliance with the language of the standard.
      
      	Some additional commentary relating to code vs. standard is also
      added.
      
      	Reported by Martin Patterson <martin@gear6.com> who also supplied
      the logic of the fix and verified the patch.
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2d6682db
  23. 31 10月, 2009 1 次提交
  24. 27 10月, 2009 1 次提交
  25. 21 9月, 2009 1 次提交
  26. 14 8月, 2009 1 次提交
  27. 13 7月, 2009 1 次提交
  28. 06 7月, 2009 1 次提交
  29. 18 5月, 2009 2 次提交
  30. 27 12月, 2008 6 次提交