1. 29 10月, 2012 5 次提交
  2. 27 10月, 2012 1 次提交
    • D
      Merge branch 'master' of git://1984.lsi.us.es/nf-next · f019948d
      David S. Miller 提交于
      Pablo Neira Ayuso says:
      
      ====================
      The following changeset contains updates for IPVS from Jesper Dangaard
      Brouer that did not reach the previous merge window in time.
      
      More specifically, updates to improve IPv6 support in IPVS. More
      relevantly, some of the existing code performed wrong handling of the
      extensions headers and better fragmentation handling.
      
      Jesper promised more follow-up patches to refine this after this batch
      hits net-next. Yet to come.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f019948d
  3. 26 10月, 2012 23 次提交
  4. 24 10月, 2012 7 次提交
  5. 23 10月, 2012 4 次提交
    • G
      ixgbevf: Update version string · 1b3d2d77
      Greg Rose 提交于
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      1b3d2d77
    • J
      ixgbevf: fix softirq-safe to unsafe splat on internal mbx_lock · 55fdd45b
      John Fastabend 提交于
      The lockdep splat below identifies a case where irq safe to unsafe
      lock order is detected. Resolved by making mbx_lock bh.
      
      ======================================================
      [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      3.6.0-rc5jk-net-next+ #119 Not tainted
      ------------------------------------------------------
      ip/2608 [HC0[0]:SC0[2]:HE1:SE0] is trying to acquire:
       (&(&adapter->mbx_lock)->rlock){+.+...}, at: [<ffffffffa008114e>] ixgbevf_set_rx_mode+0x36/0xd2 [ixgbevf]
      
      and this task is already holding:
       (_xmit_ETHER){+.....}, at: [<ffffffff814097c8>] dev_set_rx_mode+0x1e/0x33
      which would create a new lock dependency:
       (_xmit_ETHER){+.....} -> (&(&adapter->mbx_lock)->rlock){+.+...}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (&(&mc->mca_lock)->rlock){+.-...}
      ... which became SOFTIRQ-irq-safe at:
        [<ffffffff81092ee5>] __lock_acquire+0x2f2/0xdf3
        [<ffffffff81093b11>] lock_acquire+0x12b/0x158
        [<ffffffff814bdbcd>] _raw_spin_lock_bh+0x4a/0x7d
        [<ffffffffa011a740>] mld_ifc_timer_expire+0x1b2/0x282 [ipv6]
        [<ffffffff81054580>] run_timer_softirq+0x2a2/0x3ee
        [<ffffffff8104cc42>] __do_softirq+0x161/0x2b9
        [<ffffffff814c6a7c>] call_softirq+0x1c/0x30
        [<ffffffff81011bc7>] do_softirq+0x4b/0xa3
        [<ffffffff8104c8d5>] irq_exit+0x53/0xd7
        [<ffffffff814c734d>] do_IRQ+0x9d/0xb4
        [<ffffffff814be56f>] ret_from_intr+0x0/0x1a
        [<ffffffff813de21c>] cpuidle_enter+0x12/0x14
        [<ffffffff813de235>] cpuidle_enter_state+0x17/0x3f
        [<ffffffff813deb6c>] cpuidle_idle_call+0x140/0x21c
        [<ffffffff8101764c>] cpu_idle+0x79/0xcd
        [<ffffffff814a59f5>] rest_init+0x149/0x150
        [<ffffffff81ca2cbc>] start_kernel+0x37c/0x389
        [<ffffffff81ca22dd>] x86_64_start_reservations+0xb8/0xbd
        [<ffffffff81ca23e3>] x86_64_start_kernel+0x101/0x110
      
      to a SOFTIRQ-irq-unsafe lock:
       (&(&adapter->mbx_lock)->rlock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      ...  [<ffffffff81092f59>] __lock_acquire+0x366/0xdf3
        [<ffffffff81093b11>] lock_acquire+0x12b/0x158
        [<ffffffff814bd862>] _raw_spin_lock+0x45/0x7a
        [<ffffffffa0080fde>] ixgbevf_negotiate_api+0x3d/0x6d [ixgbevf]
        [<ffffffffa008404b>] ixgbevf_open+0x6c/0x43e [ixgbevf]
        [<ffffffff8140b2c1>] __dev_open+0xa0/0xe6
        [<ffffffff814099b6>] __dev_change_flags+0xbe/0x142
        [<ffffffff8140b1eb>] dev_change_flags+0x21/0x57
        [<ffffffff8141a523>] do_setlink+0x2e2/0x7f4
        [<ffffffff8141ad8c>] rtnl_newlink+0x277/0x4bb
        [<ffffffff81419c08>] rtnetlink_rcv_msg+0x236/0x253
        [<ffffffff8142f92d>] netlink_rcv_skb+0x43/0x94
        [<ffffffff814199cb>] rtnetlink_rcv+0x26/0x2d
        [<ffffffff8142f6dc>] netlink_unicast+0xee/0x174
        [<ffffffff8142ff12>] netlink_sendmsg+0x26a/0x288
        [<ffffffff813f5a0d>] __sock_sendmsg_nosec+0x58/0x61
        [<ffffffff813f7d57>] __sock_sendmsg+0x3d/0x48
        [<ffffffff813f7ed9>] sock_sendmsg+0x6e/0x87
        [<ffffffff813f93d4>] __sys_sendmsg+0x206/0x288
        [<ffffffff813f95ce>] sys_sendmsg+0x42/0x60
        [<ffffffff814c57a9>] system_call_fastpath+0x16/0x1b
      
      other info that might help us debug this:
      
      Chain exists of:
        &(&mc->mca_lock)->rlock --> _xmit_ETHER --> &(&adapter->mbx_lock)->rlock
      
       Possible interrupt unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&(&adapter->mbx_lock)->rlock);
                                     local_irq_disable();
                                     lock(&(&mc->mca_lock)->rlock);
                                     lock(_xmit_ETHER);
        <Interrupt>
          lock(&(&mc->mca_lock)->rlock);
      
       *** DEADLOCK ***
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      55fdd45b
    • G
      ixgbevf: Check for error on dma_map_single call · 6132ee8a
      Greg Rose 提交于
      Ignoring the return value from a call to the kernel dma_map API functions
      can cause data corruption and system instability.  Check the return value
      and take appropriate action.
      Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
      Tested-by: NPhil Schmitt <phillip.j.schmitt@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      6132ee8a
    • J
      ixgbevf: make netif_napi_add and netif_napi_del symmetric · f4477702
      John Fastabend 提交于
      ixgbevf_alloc_q_vectors() calls netif_napi_add for each qvector
      where qvectors is determined by the number of msix vectors. This
      makes perfect sense.
      
      However on cleanup when ixgbevf_free_q_vectors() is called and
      for each qvector we should call netif_napi_del there is some
      extra logic to add a dependency on RX queues. This patch makes
      the add/del operations symmetric by removing the RX queues
      dependency.
      
      Without this if  free_netdev() is called we see the general
      protection fault below in netif_napi_del when list_del_init()
      is called.
      
      # addr2line -e ./vmlinux ffffffff8140810c
      net-next/include/linux/list.h:88
      
      general protection fault: 0000 [#1] SMP
      Modules linked in: bonding ixgbevf ixgbe(-) mdio libfc scsi_transport_fc scsi_tgt 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 uinput coretemp lpc_ich i2c_i801 shpchp hwmon i2c_core serio_raw crc32c_intel mfd_core joydev pcspkr microcode ioatdma igb dca pata_acpi ata_generic usb_storage pata_jmicron [last unloaded: bonding]
      CPU 10
      Pid: 4174, comm: rmmod Tainted: G        W    3.6.0-rc3jk-net-next+ #104 Supermicro X8DTN/X8DTN
      RIP: 0010:[<ffffffff8140810c>]  [<ffffffff8140810c>] netif_napi_del+0x24/0x87
      RSP: 0018:ffff88027f5e9b48  EFLAGS: 00010293
      RAX: ffff8806224b4768 RBX: ffff8806224b46e8 RCX: 6b6b6b6b6b6b6b6b
      RDX: 6b6b6b6b6b6b6b6b RSI: ffffffff810bf6c5 RDI: ffff8806224b46e8
      RBP: ffff88027f5e9b58 R08: ffff88033200b180 R09: ffff88027f5e98a8
      R10: ffff88033320b000 R11: ffff88027f5e9ae8 R12: 6b6b6b6b6b6b6aeb
      R13: ffff8806221d11c0 R14: 0000000000000000 R15: ffff88027f5e9cf8
      FS:  00007f5e58b9b700(0000) GS:ffff880333200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00000000010ef2b8 CR3: 0000000281fff000 CR4: 00000000000007e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process rmmod (pid: 4174, threadinfo ffff88027f5e8000, task ffff88032f888000)
      Stack:
       ffff8806221d1160 6b6b6b6b6b6b6aeb ffff88027f5e9b88 ffffffff81408e46
       ffff8806221d1160 ffff8806221d1160 ffff8806221d1ae0 ffff8806221d5668
       ffff88027f5e9bb8 ffffffffa009153c ffffffffa0092a30 ffff8806221d5700
      Call Trace:
       [<ffffffff81408e46>] free_netdev+0x64/0xd7
       [<ffffffffa009153c>] ixgbevf_remove+0xa6/0xbc [ixgbevf]
       [<ffffffff8127a7a1>] pci_device_remove+0x2d/0x51
       [<ffffffff8131f503>] __device_release_driver+0x6c/0xc2
       [<ffffffff8131f640>] device_release_driver+0x25/0x32
       [<ffffffff8131e821>] bus_remove_device+0x148/0x15d
       [<ffffffff8131cb6b>] device_del+0x130/0x1a4
       [<ffffffff8131cc2a>] device_unregister+0x4b/0x57
       [<ffffffff81275c27>] pci_stop_bus_device+0x63/0x85
       [...]
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: NGreg Rose <gregory.v.rose@intel.com>
      Acked-by: NAlexander Duyck <alexander.h.duyck@intel.com>
      Tested-by: NSibai Li <sibai.li@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      f4477702