1. 08 8月, 2009 4 次提交
  2. 05 8月, 2009 3 次提交
    • I
      net: Fix spinlock use in alloc_netdev_mq() · 0bf52b98
      Ingo Molnar 提交于
      -tip testing found this lockdep warning:
      
      [    2.272010] calling  net_dev_init+0x0/0x164 @ 1
      [    2.276033] device class 'net': registering
      [    2.280191] INFO: trying to register non-static key.
      [    2.284005] the code is fine but needs lockdep annotation.
      [    2.284005] turning off the locking correctness validator.
      [    2.284005] Pid: 1, comm: swapper Not tainted 2.6.31-rc5-tip #1145
      [    2.284005] Call Trace:
      [    2.284005]  [<7958eb4e>] ? printk+0xf/0x11
      [    2.284005]  [<7904f83c>] __lock_acquire+0x11b/0x622
      [    2.284005]  [<7908c9b7>] ? alloc_debug_processing+0xf9/0x144
      [    2.284005]  [<7904e2be>] ? mark_held_locks+0x3a/0x52
      [    2.284005]  [<7908dbc4>] ? kmem_cache_alloc+0xa8/0x13f
      [    2.284005]  [<7904e475>] ? trace_hardirqs_on_caller+0xa2/0xc3
      [    2.284005]  [<7904fdf6>] lock_acquire+0xb3/0xd0
      [    2.284005]  [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
      [    2.284005]  [<79591514>] _spin_lock_bh+0x2d/0x5d
      [    2.284005]  [<79489678>] ? alloc_netdev_mq+0xf5/0x1ad
      [    2.284005]  [<79489678>] alloc_netdev_mq+0xf5/0x1ad
      [    2.284005]  [<793a38f2>] ? loopback_setup+0x0/0x74
      [    2.284005]  [<798eecd0>] loopback_net_init+0x20/0x5d
      [    2.284005]  [<79483efb>] register_pernet_device+0x23/0x4b
      [    2.284005]  [<798f5c9f>] net_dev_init+0x115/0x164
      [    2.284005]  [<7900104f>] do_one_initcall+0x4a/0x11a
      [    2.284005]  [<798f5b8a>] ? net_dev_init+0x0/0x164
      [    2.284005]  [<79066f6d>] ? register_irq_proc+0x8c/0xa8
      [    2.284005]  [<798cc29a>] do_basic_setup+0x42/0x52
      [    2.284005]  [<798cc30a>] kernel_init+0x60/0xa1
      [    2.284005]  [<798cc2aa>] ? kernel_init+0x0/0xa1
      [    2.284005]  [<79003e03>] kernel_thread_helper+0x7/0x10
      [    2.284078] device: 'lo': device_add
      [    2.288248] initcall net_dev_init+0x0/0x164 returned 0 after 11718 usecs
      [    2.292010] calling  neigh_init+0x0/0x66 @ 1
      [    2.296010] initcall neigh_init+0x0/0x66 returned 0 after 0 usecs
      
      it's using an zero-initialized spinlock. This is a side-effect of:
      
              dev_unicast_init(dev);
      
      in alloc_netdev_mq() making use of dev->addr_list_lock.
      
      The device has just been allocated freshly, it's not accessible
      anywhere yet so no locking is needed at all - in fact it's wrong
      to lock it here (the lock isnt initialized yet).
      
      This bug was introduced via:
      
      | commit a6ac65db
      | Date:   Thu Jul 30 01:06:12 2009 +0000
      |
      |     net: restore the original spinlock to protect unicast list
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NJiri Pirko <jpirko@redhat.com>
      Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bf52b98
    • H
      ehea: Fix napi list corruption on ifconfig down · 357eb46d
      Hannes Hering 提交于
      This patch fixes the napi list handling when an ehea interface is shut
      down to avoid corruption of the napi list.
      Signed-off-by: NHannes Hering <hering2@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      357eb46d
    • A
      igbvf: Allow VF driver to correctly recognize failure to set mac · e0cff5ed
      Alexander Duyck 提交于
      The VF driver was not correctly recognizing that it did not correctly set
      it's mac address.  As a result the VF driver was unable to receive network
      traffic until being unloaded and reloaded.  The issue was root caused to
      the fact that the CTS bit was not taken into account when checking for the
      request being NAKed.
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0cff5ed
  3. 04 8月, 2009 12 次提交
  4. 03 8月, 2009 12 次提交
  5. 31 7月, 2009 9 次提交