1. 04 12月, 2012 1 次提交
    • B
      net/intel: remove __dev* attributes · 9f9a12f8
      Bill Pemberton 提交于
      CONFIG_HOTPLUG is going away as an option.  As result the __dev*
      markings will be going away.
      
      Remove use of __devinit, __devexit_p, __devinitdata, __devinitconst,
      and __devexit.
      Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
      Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Cc: Bruce Allan <bruce.w.allan@intel.com>
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Don Skidmore <donald.c.skidmore@intel.com>
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Cc: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
      Cc: Alex Duyck <alexander.h.duyck@intel.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Tushar Dave <tushar.n.dave@intel.com>
      Cc: e1000-devel@lists.sourceforge.net
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9f9a12f8
  2. 15 11月, 2012 7 次提交
  3. 14 11月, 2012 4 次提交
  4. 03 11月, 2012 1 次提交
  5. 01 11月, 2012 1 次提交
    • J
      ixgbe: add setlink, getlink support to ixgbe and ixgbevf · 815cccbf
      John Fastabend 提交于
      This adds support for the net device ops to manage the embedded
      hardware bridge on ixgbe devices. With this patch the bridge
      mode can be toggled between VEB and VEPA to support stacking
      macvlan devices or using the embedded switch without any SW
      component in 802.1Qbg/br environments.
      
      Additionally, this adds source address pruning to the ixgbevf
      driver to prune any frames sent back from a reflective relay on
      the switch. This is required because the existing hardware does
      not support this. Without it frames get pushed into the stack
      with its own src mac which is invalid per 802.1Qbg VEPA
      definition.
      Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      815cccbf
  6. 30 10月, 2012 1 次提交
  7. 23 10月, 2012 5 次提交
    • 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
    • A
      ixgbevf: Add VF DCB + SR-IOV support · 56e94095
      Alexander Duyck 提交于
      This change adds support for DCB and SR-IOV from the VF.  With this change
      in place the VF will correctly use a traffic class other than 0 in the case
      that the PF is configured with the default user priority belonging to a
      traffic class other than 0.
      
      Cc: Greg Rose <gregory.v.rose@intel.com>
      Signed-off-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>
      56e94095
  8. 09 10月, 2012 1 次提交
  9. 24 9月, 2012 5 次提交
  10. 20 9月, 2012 1 次提交
  11. 08 9月, 2012 1 次提交
  12. 31 8月, 2012 2 次提交
  13. 01 8月, 2012 1 次提交
    • M
      netvm: propagate page->pfmemalloc from skb_alloc_page to skb · 0614002b
      Mel Gorman 提交于
      The skb->pfmemalloc flag gets set to true iff during the slab allocation
      of data in __alloc_skb that the the PFMEMALLOC reserves were used.  If
      page splitting is used, it is possible that pages will be allocated from
      the PFMEMALLOC reserve without propagating this information to the skb.
      This patch propagates page->pfmemalloc from pages allocated for fragments
      to the skb.
      
      It works by reintroducing and expanding the skb_alloc_page() API to take
      an skb.  If the page was allocated from pfmemalloc reserves, it is
      automatically copied.  If the driver allocates the page before the skb, it
      should call skb_propagate_pfmemalloc() after the skb is allocated to
      ensure the flag is copied properly.
      
      Failure to do so is not critical.  The resulting driver may perform slower
      if it is used for swap-over-NBD or swap-over-NFS but it should not result
      in failure.
      
      [davem@davemloft.net: API rename and consistency]
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Mike Christie <michaelc@cs.wisc.edu>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Christoph Lameter <cl@linux.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0614002b
  14. 22 7月, 2012 3 次提交
  15. 19 7月, 2012 4 次提交
  16. 18 7月, 2012 1 次提交
  17. 17 7月, 2012 1 次提交