1. 21 May, 2009 5 commits
    • Roel Kluin's avatar
      c40499e0
    • Jean-Mickael Guerin's avatar
      IPv6: set RTPROT_KERNEL to initial route · 4f724279
      Jean-Mickael Guerin authored
      The use of unspecified protocol in IPv6 initial route prevents quagga to
      install IPv6 default route:
      # show ipv6 route
      S   ::/0 [1/0] via fe80::1, eth1_0
      K>* ::/0 is directly connected, lo, rej
      C>* ::1/128 is directly connected, lo
      C>* fe80::/64 is directly connected, eth1_0
      
      # ip -6 route
      fe80::/64 dev eth1_0  proto kernel  metric 256  mtu 1500 advmss 1440
      hoplimit -1
      ff00::/8 dev eth1_0  metric 256  mtu 1500 advmss 1440 hoplimit -1
      unreachable default dev lo  proto none  metric -1  error -101 hoplimit 255
      
      The attached patch ensures RTPROT_KERNEL to the default initial route
      and fixes the problem for quagga.
      This is similar to "ipv6: protocol for address routes"
      f410a1fb.
      
      # show ipv6 route
      S>* ::/0 [1/0] via fe80::1, eth1_0
      C>* ::1/128 is directly connected, lo
      C>* fe80::/64 is directly connected, eth1_0
      
      # ip -6 route
      fe80::/64 dev eth1_0  proto kernel  metric 256  mtu 1500 advmss 1440
      hoplimit -1
      fe80::/64 dev eth1_0  proto kernel  metric 256  mtu 1500 advmss 1440
      hoplimit -1
      ff00::/8 dev eth1_0  metric 256  mtu 1500 advmss 1440 hoplimit -1
      default via fe80::1 dev eth1_0  proto zebra  metric 1024  mtu 1500
      advmss 1440 hoplimit -1
      unreachable default dev lo  proto kernel  metric -1  error -101 hoplimit 255
      Signed-off-by: default avatarJean-Mickael Guerin <jean-mickael.guerin@6wind.com>
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4f724279
    • David S. Miller's avatar
    • Eric Dumazet's avatar
      net: fix rtable leak in net/ipv4/route.c · 1ddbcb00
      Eric Dumazet authored
      Alexander V. Lukyanov found a regression in 2.6.29 and made a complete
      analysis found in http://bugzilla.kernel.org/show_bug.cgi?id=13339
      Quoted here because its a perfect one :
      
      begin_of_quotation
       2.6.29 patch has introduced flexible route cache rebuilding. Unfortunately the
       patch has at least one critical flaw, and another problem.
      
       rt_intern_hash calculates rthi pointer, which is later used for new entry
       insertion. The same loop calculates cand pointer which is used to clean the
       list. If the pointers are the same, rtable leak occurs, as first the cand is
       removed then the new entry is appended to it.
      
       This leak leads to unregister_netdevice problem (usage count > 0).
      
       Another problem of the patch is that it tries to insert the entries in certain
       order, to facilitate counting of entries distinct by all but QoS parameters.
       Unfortunately, referencing an existing rtable entry moves it to list beginning,
       to speed up further lookups, so the carefully built order is destroyed.
      
       For the first problem the simplest patch it to set rthi=0 when rthi==cand, but
       it will also destroy the ordering.
      end_of_quotation
      
      Problematic commit is 1080d709
      (net: implement emergency route cache rebulds when gc_elasticity is exceeded)
      
      Trying to keep dst_entries ordered is too complex and breaks the fact that
      order should depend on the frequency of use for garbage collection.
      
      A possible fix is to make rt_intern_hash() simpler, and only makes
      rt_check_expire() a litle bit smarter, being able to cope with an arbitrary
      entries order. The added loop is running on cache hot data, while cpu
      is prefetching next object, so should be unnoticied.
      Reported-and-analyzed-by: default avatarAlexander V. Lukyanov <lav@yar.ru>
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ddbcb00
    • Eric Dumazet's avatar
      net: fix length computation in rt_check_expire() · cf8da764
      Eric Dumazet authored
      rt_check_expire() computes average and standard deviation of chain lengths,
      but not correclty reset length to 0 at beginning of each chain.
      This probably gives overflows for sum2 (and sum) on loaded machines instead
      of meaningful results.
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf8da764
  2. 20 May, 2009 9 commits
  3. 19 May, 2009 3 commits
  4. 18 May, 2009 14 commits
    • Ajit Khaparde's avatar
    • Eric Dumazet's avatar
      sch_teql: should not dereference skb after ndo_start_xmit() · c0f84d0d
      Eric Dumazet authored
      It is illegal to dereference a skb after a successful ndo_start_xmit()
      call. We must store skb length in a local variable instead.
      
      Bug was introduced in 2.6.27 by commit 0abf77e5
      (net_sched: Add accessor function for packet length for qdiscs)
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0f84d0d
    • Ilpo Järvinen's avatar
      tcp: fix MSG_PEEK race check · 77527313
      Ilpo Järvinen authored
      Commit 518a09ef (tcp: Fix recvmsg MSG_PEEK influence of
      blocking behavior) lets the loop run longer than the race check
      did previously expect, so we need to be more careful with this
      check and consider the work we have been doing.
      
      I tried my best to deal with urg hole madness too which happens
      here:
      	if (!sock_flag(sk, SOCK_URGINLINE)) {
      		++*seq;
      		...
      by using additional offset by one but I certainly have very
      little interest in testing that part.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Tested-by: default avatarFrans Pop <elendil@planet.nl>
      Tested-by: default avatarIan Zimmermann <itz@buug.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      77527313
    • Wang Tinggong's avatar
    • roel kluin's avatar
      Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR? · d77dd8d2
      roel kluin authored
      FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
      Signed-off-by: default avatarRoel Kluin <roel.kluin@gmail.com>
      Acked-by: default avatarRam Vepa <ram.vepa@neterion.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d77dd8d2
    • Gabriel Paubert's avatar
      mv643xx_eth: fix PPC DMA breakage · eb0519b5
      Gabriel Paubert authored
      After 2.6.29, PPC no more admits passing NULL to the dev parameter of
      the DMA API. The result is a BUG followed by solid lock-up when the 
      mv643xx_eth driver brings an interface up. The following patch makes 
      the driver work on my Pegasos again; it is mostly a search and replace 
      of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
      functions.
      Signed-off-by: default avatarGabriel Paubert <paubert@iram.es>
      Acked-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb0519b5
    • Stephen Hemminger's avatar
      bonding: fix link down handling in 802.3ad mode · 4cd6fe1c
      Stephen Hemminger authored
      One of the purposes of bonding is to allow for redundant links, and failover
      correctly if the cable is pulled. If all the members of a bonded device have
      no carrier present, the bonded device itself needs to report no carrier present
      to user space so management tools (like routing daemons) can respond.
      
      Bonding in 802.3ad mode does not work correctly for this because it incorrectly
      chooses a link that is down as a possible aggregator.
      Signed-off-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cd6fe1c
    • David S. Miller's avatar
    • 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
  5. 17 May, 2009 1 commit
  6. 16 May, 2009 8 commits