1. 06 3月, 2018 3 次提交
  2. 25 1月, 2018 5 次提交
    • M
      igb: Delete an error message for a failed memory allocation in igb_enable_sriov() · 13169bad
      Markus Elfring 提交于
      Omit an extra message for a memory allocation failure in this function.
      
      This issue was detected by using the Coccinelle software.
      Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      13169bad
    • L
      igb: Free IRQs when device is hotplugged · 888f2293
      Lyude Paul 提交于
      Recently I got a Caldigit TS3 Thunderbolt 3 dock, and noticed that upon
      hotplugging my kernel would immediately crash due to igb:
      
      [  680.825801] kernel BUG at drivers/pci/msi.c:352!
      [  680.828388] invalid opcode: 0000 [#1] SMP
      [  680.829194] Modules linked in: igb(O) thunderbolt i2c_algo_bit joydev vfat fat btusb btrtl btbcm btintel bluetooth ecdh_generic hp_wmi sparse_keymap rfkill wmi_bmof iTCO_wdt intel_rapl x86_pkg_temp_thermal coretemp crc32_pclmul snd_pcm rtsx_pci_ms mei_me snd_timer memstick snd pcspkr mei soundcore i2c_i801 tpm_tis psmouse shpchp wmi tpm_tis_core tpm video hp_wireless acpi_pad rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci mfd_core xhci_pci xhci_hcd i2c_hid i2c_core [last unloaded: igb]
      [  680.831085] CPU: 1 PID: 78 Comm: kworker/u16:1 Tainted: G           O     4.15.0-rc3Lyude-Test+ #6
      [  680.831596] Hardware name: HP HP ZBook Studio G4/826B, BIOS P71 Ver. 01.03 06/09/2017
      [  680.832168] Workqueue: kacpi_hotplug acpi_hotplug_work_fn
      [  680.832687] RIP: 0010:free_msi_irqs+0x180/0x1b0
      [  680.833271] RSP: 0018:ffffc9000030fbf0 EFLAGS: 00010286
      [  680.833761] RAX: ffff8803405f9c00 RBX: ffff88033e3d2e40 RCX: 000000000000002c
      [  680.834278] RDX: 0000000000000000 RSI: 00000000000000ac RDI: ffff880340be2178
      [  680.834832] RBP: 0000000000000000 R08: ffff880340be1ff0 R09: ffff8803405f9c00
      [  680.835342] R10: 0000000000000000 R11: 0000000000000040 R12: ffff88033d63a298
      [  680.835822] R13: ffff88033d63a000 R14: 0000000000000060 R15: ffff880341959000
      [  680.836332] FS:  0000000000000000(0000) GS:ffff88034f440000(0000) knlGS:0000000000000000
      [  680.836817] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  680.837360] CR2: 000055e64044afdf CR3: 0000000001c09002 CR4: 00000000003606e0
      [  680.837954] Call Trace:
      [  680.838853]  pci_disable_msix+0xce/0xf0
      [  680.839616]  igb_reset_interrupt_capability+0x5d/0x60 [igb]
      [  680.840278]  igb_remove+0x9d/0x110 [igb]
      [  680.840764]  pci_device_remove+0x36/0xb0
      [  680.841279]  device_release_driver_internal+0x157/0x220
      [  680.841739]  pci_stop_bus_device+0x7d/0xa0
      [  680.842255]  pci_stop_bus_device+0x2b/0xa0
      [  680.842722]  pci_stop_bus_device+0x3d/0xa0
      [  680.843189]  pci_stop_and_remove_bus_device+0xe/0x20
      [  680.843627]  trim_stale_devices+0xf3/0x140
      [  680.844086]  trim_stale_devices+0x94/0x140
      [  680.844532]  trim_stale_devices+0xa6/0x140
      [  680.845031]  ? get_slot_status+0x90/0xc0
      [  680.845536]  acpiphp_check_bridge.part.5+0xfe/0x140
      [  680.846021]  acpiphp_hotplug_notify+0x175/0x200
      [  680.846581]  ? free_bridge+0x100/0x100
      [  680.847113]  acpi_device_hotplug+0x8a/0x490
      [  680.847535]  acpi_hotplug_work_fn+0x1a/0x30
      [  680.848076]  process_one_work+0x182/0x3a0
      [  680.848543]  worker_thread+0x2e/0x380
      [  680.848963]  ? process_one_work+0x3a0/0x3a0
      [  680.849373]  kthread+0x111/0x130
      [  680.849776]  ? kthread_create_worker_on_cpu+0x50/0x50
      [  680.850188]  ret_from_fork+0x1f/0x30
      [  680.850601] Code: 43 14 85 c0 0f 84 d5 fe ff ff 31 ed eb 0f 83 c5 01 39 6b 14 0f 86 c5 fe ff ff 8b 7b 10 01 ef e8 b7 e4 d2 ff 48 83 78 70 00 74 e3 <0f> 0b 49 8d b5 a0 00 00 00 e8 62 6f d3 ff e9 c7 fe ff ff 48 8b
      [  680.851497] RIP: free_msi_irqs+0x180/0x1b0 RSP: ffffc9000030fbf0
      
      As it turns out, normally the freeing of IRQs that would fix this is called
      inside of the scope of __igb_close(). However, since the device is
      already gone by the point we try to unregister the netdevice from the
      driver due to a hotplug we end up seeing that the netif isn't present
      and thus, forget to free any of the device IRQs.
      
      So: make sure that if we're in the process of dismantling the netdev, we
      always allow __igb_close() to be called so that IRQs may be freed
      normally. Additionally, only allow igb_close() to be called from
      __igb_close() if it hasn't already been called for the given adapter.
      Signed-off-by: NLyude Paul <lyude@redhat.com>
      Fixes: 9474933c ("igb: close/suspend race in netif_device_detach")
      Cc: Todd Fujinaka <todd.fujinaka@intel.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: stable@vger.kernel.org
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      888f2293
    • J
      igb: Clarify idleslope config constraints · 0da6090f
      Jesus Sanchez-Palencia 提交于
      By design, the idleslope increments are restricted to 16.384kbps steps.
      Add a comment to igb_main.c making that explicit and add one example
      that illustrates the impact of that.
      Signed-off-by: NJesus Sanchez-Palencia <jesus.sanchez-palencia@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0da6090f
    • Z
      igb: add function to get maximum RSS queues · 28cb2d1b
      Zhang Shengju 提交于
      This patch adds a new function igb_get_max_rss_queues() to get maximum
      RSS queues, this will reduce duplicate code and facilitate future
      maintenance.
      Signed-off-by: NZhang Shengju <zhangshengju@cmss.chinamobile.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      28cb2d1b
    • C
      igb: Allow to remove administratively set MAC on VFs · 177132df
      Corinna Vinschen 提交于
      Before libvirt modifies the MAC address and vlan tag for an SRIOV VF
      for use by a virtual machine (either using vfio device assignment or
      macvtap passthru mode), it saves the current MAC address and vlan tag
      so that it can reset them to their original value when the guest is
      done.  Libvirt can't leave the VF MAC set to the value used by the
      now-defunct guest since it may be started again later using a
      different VF, but it certainly shouldn't just pick any random value,
      either. So it saves the state of everything prior to using the VF, and
      resets it to that.
      
      The igb driver initializes the MAC addresses of all VFs to
      00:00:00:00:00:00, and reports that when asked (via an RTM_GETLINK
      netlink message, also visible in the list of VFs in the output of "ip
      link show"). But when libvirt attempts to restore the MAC address back
      to 00:00:00:00:00:00 (using an RTM_SETLINK netlink message) the kernel
      responds with "Invalid argument".
      
      Forbidding a reset back to the original value leaves the VF MAC at the
      value set for the now-defunct virtual machine. Especially on a system
      with NetworkManager enabled, this has very bad consequences, since
      NetworkManager forces all interfacess to be IFF_UP all the time - if
      the same virtual machine is restarted using a different VF (or even on
      a different host), there will be multiple interfaces watching for
      traffic with the same MAC address.
      
      To allow libvirt to revert to the original state, we need a way to
      remove the administrative set MAC on a VF, to allow normal host
      operation again, and to reset/overwrite the VF MAC via VF netdev.
      
      This patch implements the outlined scenario by allowing to set the
      VF MAC to 00:00:00:00:00:00 via RTM_SETLINK on the PF.
      igb_ndo_set_vf_mac resets the IGB_VF_FLAG_PF_SET_MAC flag to 0,
      so it's possible to reset the VF MAC back to the original value via
      the VF netdev.
      
      Note: Recent patches to libvirt allow for a workaround if the NIC
      isn't capable of resetting the administrative MAC back to all 0, but
      in theory the NIC should allow resetting the MAC in the first place.
      Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
      Tested-by: NAaron Brown <arron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      177132df
  3. 22 11月, 2017 1 次提交
  4. 08 11月, 2017 1 次提交
  5. 28 10月, 2017 1 次提交
    • A
      igb: Add support for CBS offload · 05f9d3e1
      Andre Guedes 提交于
      This patch adds support for Credit-Based Shaper (CBS) qdisc offload
      from Traffic Control system. This support enable us to leverage the
      Forwarding and Queuing for Time-Sensitive Streams (FQTSS) features
      from Intel i210 Ethernet Controller. FQTSS is the former 802.1Qav
      standard which was merged into 802.1Q in 2014. It enables traffic
      prioritization and bandwidth reservation via the Credit-Based Shaper
      which is implemented in hardware by i210 controller.
      
      The patch introduces the igb_setup_tc() function which implements the
      support for CBS qdisc hardware offload in the IGB driver. CBS offload
      is the only traffic control offload supported by the driver at the
      moment.
      
      FQTSS transmission mode from i210 controller is automatically enabled
      by the IGB driver when the CBS is enabled for the first hardware
      queue. Likewise, FQTSS mode is automatically disabled when CBS is
      disabled for the last hardware queue. Changing FQTSS mode requires NIC
      reset.
      
      FQTSS feature is supported by i210 controller only.
      Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Tested-by: NHenrik Austad <henrik@austad.us>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      05f9d3e1
  6. 26 10月, 2017 1 次提交
  7. 25 10月, 2017 1 次提交
    • M
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns... · 6aa7de05
      Mark Rutland 提交于
      locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()
      
      Please do not apply this to mainline directly, instead please re-run the
      coccinelle script shown below and apply its output.
      
      For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
      preference to ACCESS_ONCE(), and new code is expected to use one of the
      former. So far, there's been no reason to change most existing uses of
      ACCESS_ONCE(), as these aren't harmful, and changing them results in
      churn.
      
      However, for some features, the read/write distinction is critical to
      correct operation. To distinguish these cases, separate read/write
      accessors must be used. This patch migrates (most) remaining
      ACCESS_ONCE() instances to {READ,WRITE}_ONCE(), using the following
      coccinelle script:
      
      ----
      // Convert trivial ACCESS_ONCE() uses to equivalent READ_ONCE() and
      // WRITE_ONCE()
      
      // $ make coccicheck COCCI=/home/mark/once.cocci SPFLAGS="--include-headers" MODE=patch
      
      virtual patch
      
      @ depends on patch @
      expression E1, E2;
      @@
      
      - ACCESS_ONCE(E1) = E2
      + WRITE_ONCE(E1, E2)
      
      @ depends on patch @
      expression E;
      @@
      
      - ACCESS_ONCE(E)
      + READ_ONCE(E)
      ----
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: davem@davemloft.net
      Cc: linux-arch@vger.kernel.org
      Cc: mpe@ellerman.id.au
      Cc: shuah@kernel.org
      Cc: snitzer@redhat.com
      Cc: thor.thayer@linux.intel.com
      Cc: tj@kernel.org
      Cc: viro@zeniv.linux.org.uk
      Cc: will.deacon@arm.com
      Link: http://lkml.kernel.org/r/1508792849-3115-19-git-send-email-paulmck@linux.vnet.ibm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      6aa7de05
  8. 18 10月, 2017 1 次提交
  9. 11 10月, 2017 1 次提交
  10. 09 8月, 2017 4 次提交
    • G
      igb: do not drop PF mailbox lock after read of VF message · 46b3bb9b
      Greg Edwards 提交于
      When the PF receives a mailbox message from the VF, it grabs the mailbox
      lock, reads the VF message from the mailbox, ACKs the message and drops
      the lock.
      
      While the PF is performing the action for the VF message, nothing
      prevents another VF message from being posted to the mailbox.  The
      current code handles this condition by just dropping any new VF messages
      without processing them.  This results in a mailbox timeout in the VM
      for posted messages waiting for an ACK, and the VF is reset by the
      igbvf_watchdog_task in the VM.
      
      Given the right sequence of VF messages and mailbox timeouts, this
      condition can go on ad infinitum.
      
      Modify the PF mailbox read method to take an 'unlock' argument that
      optionally leaves the mailbox locked by the PF after reading the VF
      message.  This ensures another VF message is not posted to the mailbox
      until after the PF has completed processing the VF message and written
      its reply.
      Signed-off-by: NGreg Edwards <gedwards@ddn.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      46b3bb9b
    • C
      igb: Remove incorrect "unexpected SYS WRAP" log message · 2643e6e9
      Corinna Vinschen 提交于
      TSAUXC.DisableSystime is never set, so SYSTIM runs into a SYS WRAP
      every 1100 secs on 80580/i350/i354 (40 bit SYSTIM) and every 35000
      secs on 80576 (45 bit SYSTIM).
      
      This wrap event sets the TSICR.SysWrap bit unconditionally.
      
      However, checking TSIM at interrupt time shows that this event does not
      actually cause the interrupt.  Rather, it's just bycatch while the
      actual interrupt is caused by, for instance, TSICR.TXTS.
      
      The conclusion is that the SYS WRAP is actually expected, so the
      "unexpected SYS WRAP" message is entirely bogus and just helps to
      confuse users.  Drop it.
      Signed-off-by: NCorinna Vinschen <vinschen@redhat.com>
      Acked-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      2643e6e9
    • C
      igb: protect TX timestamping from API misuse · 26bd4e2d
      Cliff Spradlin 提交于
      HW timestamping can only be requested for a packet if the NIC is first
      setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the igb
      driver still allowed TX packets to request HW timestamping. In this
      situation, the _IGB_PTP_TX_IN_PROGRESS flag was set and would never
      clear. This prevented any future HW timestamping requests to succeed.
      
      Fix this by checking that the NIC is configured for HW TX timestamping
      before accepting a HW TX timestamping request.
      Signed-off-by: NCliff Spradlin <cspradlin@google.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      26bd4e2d
    • G
      igb: Fix error of RX network flow classification · 94221ae7
      Gangfeng Huang 提交于
      After add an ethertype filter, if user change the adapter speed several
      times, the error "ethtool -N: etype filters are all used" is reported by
      igb driver.
      
      In older patch, function igb_nfc_filter_exit() and igb_nfc_filter_restore()
      is not paried. igb_nfc_filter_restore() exist in igb_up(), but function
      igb_nfc_filter_exit() is exist in __igb_close(). In the process of speed
      changing, only igb_nfc_filter_restore() is called, it will take a position
      of ethertype bitmap.
      
      Reproduce steps:
      Step 1: Add a etype filter by ethtool
      $ethtool -N eth0 flow-type ether proto 0x88F8 action 1
      Step 2: Change the adapter speed to 100M/full duplex
      $ethtool -s eth0 speed 100 duplex full
      Step 3: Change the adapter speed to 1000M/full duplex
      ethtool -s eth0 speed 1000 duplex full
      Repeat step2 and step3, then dmesg the system log, you can find the error
      message, add new ethtype filter is also failed.
      
      This fixing is move igb_nfc_filter_exit() from __igb_close() to igb_down()
      to make igb_nfc_filter_restore()/igb_nfc_filter_exit() is paired.
      Signed-off-by: NGangfeng Huang <gangfeng.huang@ni.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      94221ae7
  11. 08 6月, 2017 1 次提交
  12. 06 6月, 2017 5 次提交
  13. 21 4月, 2017 3 次提交
  14. 18 3月, 2017 11 次提交
  15. 19 1月, 2017 1 次提交
    • T
      net: Remove usage of net_device last_rx member · 4a7c9726
      Tobias Klauser 提交于
      The network stack no longer uses the last_rx member of struct net_device
      since the bonding driver switched to use its own private last_rx in
      commit 9f242738 ("bonding: use last_arp_rx in slave_last_rx()").
      
      However, some drivers still (ab)use the field for their own purposes and
      some driver just update it without actually using it.
      
      Previously, there was an accompanying comment for the last_rx member
      added in commit 4dc89133 ("net: add a comment on netdev->last_rx")
      which asked drivers not to update is, unless really needed. However,
      this commend was removed in commit f8ff080d ("bonding: remove
      useless updating of slave->dev->last_rx"), so some drivers added later
      on still did update last_rx.
      
      Remove all usage of last_rx and switch three drivers (sky2, atp and
      smc91c92_cs) which actually read and write it to use their own private
      copy in netdev_priv.
      
      Compile-tested with allyesconfig and allmodconfig on x86 and arm.
      
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jay Vosburgh <j.vosburgh@gmail.com>
      Cc: Veaceslav Falico <vfalico@gmail.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Reviewed-by: NJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a7c9726