1. 18 May, 2009 6 commits
    • Stephen Hemminger's avatar
      bridge: fix initial packet flood if !STP · 4f0611af
      Stephen Hemminger authored
      If bridge is configured with no STP and forwarding delay of 0 (which
      is typical for virtualization) then when link starts it will flood all
      packets for the first 20 seconds.
      
      This bug was introduced by a combination of earlier changes:
        * forwarding database uses hold time of zero to indicate
          user wants to always flood packets
        * optimzation of the case of forwarding delay of 0 avoids the initial
          timer tick
      
      The fix is to just skip all the topology change detection code if
      kernel STP is not being used.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f0611af
    • Stephen Hemminger's avatar
      bridge: relay bridge multicast pkgs if !STP · a598f6ae
      Stephen Hemminger authored
      Currently the bridge catches all STP packets; even if STP is turned
      off.  This prevents other systems (which do have STP turned on)
      from being able to detect loops in the network.
      
      With this patch, if STP is off, then any packet sent to the STP
      multicast group address is forwarded to all ports.
      
      Based on earlier patch by Joakim Tjernlund with changes
      to go through forwarding (not local chain), and optimization
      that only last octet needs to be checked.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a598f6ae
    • Ralf Baechle's avatar
      NET: Meth: Fix unsafe mix of irq and non-irq spinlocks. · a8f492c6
      Ralf Baechle authored
      Mixing of normal and irq spinlocks results in the following lockdep messages
      on bootup on IP32:
      
      [...]
      Sending DHCP requests .
      ======================================================
      [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      2.6.30-rc5-00164-g41baeef #30
      ------------------------------------------------------
      swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
       (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
      
      and this task is already holding:
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      which would create a new lock dependency:
       (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (_xmit_ETHER#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
        [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
        [<ffffffff80004420>] ret_from_irq+0x0/0x4
        [<ffffffff80004720>] r4k_wait+0x20/0x40
        [<ffffffff80015418>] cpu_idle+0x30/0x60
        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
      
      to a SOFTIRQ-irq-unsafe lock:
       (&priv->meth_lock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      ...  [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
        [<ffffffff8026424c>] meth_open+0x28/0x140
        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
        [<ffffffff804cd190>] kernel_init+0x98/0x104
        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      other info that might help us debug this:
      
      2 locks held by swapper/1:
       #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
       #1:  (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      
      the SOFTIRQ-irq-safe lock's dependencies:
      -> (_xmit_ETHER#2){+.-...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         IN-SOFTIRQ-W at:
                              [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                             [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                             [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                             [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                             [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                             [<ffffffff80004420>] ret_from_irq+0x0/0x4
                             [<ffffffff80004720>] r4k_wait+0x20/0x40
                             [<ffffffff80015418>] cpu_idle+0x30/0x60
                             [<ffffffff804cd934>] start_kernel+0x3ec/0x404
       }
       ... key      at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8
      
      the SOFTIRQ-irq-unsafe lock's dependencies:
      -> (&priv->meth_lock){+.+...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         SOFTIRQ-ON-W at:
                              [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                             [<ffffffff8026424c>] meth_open+0x28/0x140
                             [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                             [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                             [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                             [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                             [<ffffffff804cd190>] kernel_init+0x98/0x104
                             [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
       }
       ... key      at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8
      
      stack backtrace:
      Call Trace:
      [<ffffffff8000ed0c>] dump_stack+0x8/0x34
      [<ffffffff80060b74>] check_usage+0x470/0x4a0
      [<ffffffff80060c34>] check_irq_usage+0x90/0x130
      [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
      [<ffffffff800627e0>] lock_acquire+0xf8/0x150
      [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
      [<ffffffff8026388c>] meth_tx+0x48/0x43c
      [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
      [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
      [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
      [<ffffffff80012e68>] do_one_initcall+0x58/0x170
      [<ffffffff804cd190>] kernel_init+0x98/0x104
      [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      ..... timed out!
      IP-Config: Retrying forever (NFS root)...
      Sending DHCP requests ., OK
      [...]
      
      Fixed by converting all locks to irq locks.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Tested-by: default avatarAndrew Randrianasulu <randrik_a@yahoo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8f492c6
    • Yevgeny Petrilin's avatar
      mlx4_en: Fix not deleted napi structures · 72876a60
      Yevgeny Petrilin authored
      Napi structures are being created each time we open a port, but when
      the port is closed the napi structure is only disabled but not removed.
      This bug caused hang while removing the driver.
      Signed-off-by: default avatarYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      72876a60
    • Chris Friesen's avatar
      ipconfig: handle case of delayed DHCP server · 2513dfb8
      Chris Friesen authored
      If a DHCP server is delayed, it's possible for the client to receive the 
      DHCPOFFER after it has already sent out a new DHCPDISCOVER message from 
      a second interface.  The client then sends out a DHCPREQUEST from the 
      second interface, but the server doesn't recognize the device and 
      rejects the request.
      
      This patch simply tracks the current device being configured and throws 
      away the OFFER if it is not intended for the current device.  A more 
      sophisticated approach would be to put the OFFER information into the 
      struct ic_device rather than storing it globally.
      Signed-off-by: default avatarChris Friesen <cfriesen@nortel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2513dfb8
    • Pavel Emelyanov's avatar
      netpoll: don't dereference NULL dev from np · 5e392739
      Pavel Emelyanov authored
      It looks like the dev in netpoll_poll can be NULL - at lease it's
      checked at the function beginning. Thus the dev->netde_ops dereference
      looks dangerous.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5e392739
  2. 17 May, 2009 1 commit
  3. 16 May, 2009 16 commits
  4. 15 May, 2009 17 commits