1. 02 Oct, 2017 12 commits
  2. 01 Oct, 2017 16 commits
  3. 30 Sep, 2017 3 commits
    • Colin Ian King's avatar
      mkiss: remove redundant check on len being zero · 45c1fd61
      Colin Ian King authored
      The check on len is redundant as it is always greater than 1,
      so just remove it and make the printk less complex.
      
      Detected by CoverityScan, CID#1226729 ("Logically dead code")
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      45c1fd61
    • Maciej Żenczykowski's avatar
      net-ipv6: add support for sockopt(SOL_IPV6, IPV6_FREEBIND) · 84e14fe3
      Maciej Żenczykowski authored
      So far we've been relying on sockopt(SOL_IP, IP_FREEBIND) being usable
      even on IPv6 sockets.
      
      However, it turns out it is perfectly reasonable to want to set freebind
      on an AF_INET6 SOCK_RAW socket - but there is no way to set any SOL_IP
      socket option on such a socket (they're all blindly errored out).
      
      One use case for this is to allow spoofing src ip on a raw socket
      via sendmsg cmsg.
      
      Tested:
        built, and booted
        # python
        >>> import socket
        >>> SOL_IP = socket.SOL_IP
        >>> SOL_IPV6 = socket.IPPROTO_IPV6
        >>> IP_FREEBIND = 15
        >>> IPV6_FREEBIND = 78
        >>> s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, 0)
        >>> s.getsockopt(SOL_IP, IP_FREEBIND)
        0
        >>> s.getsockopt(SOL_IPV6, IPV6_FREEBIND)
        0
        >>> s.setsockopt(SOL_IPV6, IPV6_FREEBIND, 1)
        >>> s.getsockopt(SOL_IP, IP_FREEBIND)
        1
        >>> s.getsockopt(SOL_IPV6, IPV6_FREEBIND)
        1
      Signed-off-by: default avatarMaciej Żenczykowski <maze@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84e14fe3
    • Mike Manning's avatar
      net: ipv6: send NS for DAD when link operationally up · 1f372c7b
      Mike Manning authored
      The NS for DAD are sent on admin up as long as a valid qdisc is found.
      A race condition exists by which these packets will not egress the
      interface if the operational state of the lower device is not yet up.
      The solution is to delay DAD until the link is operationally up
      according to RFC2863. Rather than only doing this, follow the existing
      code checks by deferring IPv6 device initialization altogether. The fix
      allows DAD on devices like tunnels that are controlled by userspace
      control plane. The fix has no impact on regular deployments, but means
      that there is no IPv6 connectivity until the port has been opened in
      the case of port-based network access control, which should be
      desirable.
      Signed-off-by: default avatarMike Manning <mmanning@brocade.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f372c7b
  4. 29 Sep, 2017 9 commits
    • Mitch Williams's avatar
      i40e: refactor FW version checking · 22b96551
      Mitch Williams authored
      The i40e driver now supports two different devices with two different
      firmware versions. So be smart about how we handle these. Move the FW
      version macros to the appropriate header file, and add a convenience
      macro that checks the version based on the device. Then use this macro
      to check whether or not the driver can use the new link info API.
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      22b96551
    • Alan Brady's avatar
      i40e: Enable VF to negotiate number of allocated queues · a3f5aa90
      Alan Brady authored
      Currently the PF allocates a default number of queues for each VF and
      cannot be changed.  This patch enables the VF to request a different
      number of queues allocated to it.  This patch also adds a new virtchnl
      op and capability flag to facilitate this negotiation.
      
      After the PF receives a request message, it will set a requested number
      of queues for that VF.  Then when the VF resets, its VSI will get a new
      number of queues allocated to it.
      
      This is a best effort request and since we only allocate a guaranteed
      default number, if the VF tries to ask for more than the guaranteed
      number, there may not be enough in HW to accommodate it unless other
      queues for other VFs are freed. It should also be noted decreasing the
      number queues allocated to a VF to below the default will NOT enable the
      allocation of more than 32 VFs per PF and will not free queues guaranteed
      to each VF by default.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a3f5aa90
    • Alan Brady's avatar
      i40evf: fix ring to vector mapping · c97fc9b6
      Alan Brady authored
      The current implementation for mapping queues to vectors is broken
      because it attempts to map each Tx and Rx ring to its own vector,
      however we use combined queues so we should actually be mapping the
      Tx/Rx rings together on one vector.
      
      Also in the current implementation, in the case where we have more
      queues than vectors, we attempt to group the queues together into
      'chunks' and map each 'chunk' of queues to a vector.  Chunking them
      together would be more ideal if, and only if, we only had RSS because of
      the way the hashing algorithm works but in the case of a future patch
      that enables VF ADq, round robin assignment is better and still works
      with RSS.
      
      This patch resolves both those issues and simplifies the code needed to
      accomplish this.  Instead of treating the case where we have more queues
      than vectors as special, if we notice our vector index is greater than
      vectors, reset the vector index to zero and continue mapping.  This
      should ensure that in both cases, whether we have enough vectors for
      each queue or not, the queues get appropriately mapped.
      Signed-off-by: default avatarAlan Brady <alan.brady@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c97fc9b6
    • Jacob Keller's avatar
      i40e: shutdown all IRQs and disable MSI-X when suspended · b980c063
      Jacob Keller authored
      On some platforms with a large number of CPUs, we will allocate many IRQ
      vectors. When hibernating, the system will attempt to migrate all of the
      vectors back to CPU0 when shutting down all the other CPUs. It is
      possible that we have so many vectors that it cannot re-assign them to
      CPU0. This is even more likely if we have many devices installed in one
      platform.
      
      The end result is failure to hibernate, as it is not possible to
      shutdown the CPUs. We can avoid this by disabling MSI-X and clearing our
      interrupt scheme when the device is suspended. A more ideal solution
      would be some method for the stack to properly handle this for all
      drivers, rather than on a case-by-case basis for each driver to fix
      itself.
      
      However, until this more ideal solution exists, we can do our part and
      shutdown our IRQs during suspend, which should allow systems with
      a large number of CPUs to safely suspend or hibernate.
      
      It may be worth investigating if we should shut down even further when
      we suspend as it may make the path cleaner, but this was the minimum fix
      for the hibernation issue mentioned here.
      
      Testing-hints:
        This affects systems with a large number of CPUs, and with multiple
        devices enabled. Without this change, those platforms are unable to
        hibernate at all.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      b980c063
    • Jacob Keller's avatar
      i40e: prevent service task from running while we're suspended · 5c499228
      Jacob Keller authored
      Although the service task does check the suspended status before
      running, it might already be part way through running when we go to
      suspend. Lets ensure that the service task is stopped and will not be
      restarted again until we finish resuming. This ensures that service task
      code does not cause strange interactions with the suspend/resume
      handlers.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      5c499228
    • Jacob Keller's avatar
      i40e: don't clear suspended state until we finish resuming · 401586c2
      Jacob Keller authored
      When handling suspend and resume callbacks we want to make sure that (a)
      we don't suspend again if we're already suspended and (b) we don't
      resume again if we're already resuming. Lets make sure we test_and_set
      the __I40E_SUSPENDED bit in i40e_suspend which ensures that a suspend
      call when already suspended will exit early. Additionally, if
      __I40E_SUSPENDED is not set when we begin resuming, exit early as well.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      401586c2
    • Jacob Keller's avatar
      i40e: use newer generic PM support instead of legacy PM callbacks · 0e5d3da4
      Jacob Keller authored
      Stop using the old legacy PM support, since we now have stable support
      for the newer generic PM callbacks.
      
      This has several advantages. First, we no longer have to manage our
      own pci_save_state() and power changes, as it's preferred to have the
      PCI stack do this. Second, these routines get called for both hibernate
      and suspend to ram, so we can have the driver properly handle all the
      suspend/resume flows that it needs to.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      0e5d3da4
    • Jacob Keller's avatar
      i40e: use separate state bit for miscellaneous IRQ setup · c17401a1
      Jacob Keller authored
      We currently (mis)use the __I40E_RECOVERY_PENDING bit to determine when
      we should actually request a new IRQ in i40e_setup_misc_vector().
      
      This led to a design mistake where we open-coded the re-setup of the
      miscellaneous vector in i40e_resume() instead of using the function
      provided. If we did not open-code this and instead tried to use the
      i40e_setup_misc_vector() function, it would lead to never reallocating
      the IRQ.
      
      This would lead to a second i40e_suspend() call failing to free the
      vector due to a NULL pointer dereference.
      
      A future patch is going to re-work how the i40e_suspend() and
      i40e_resume() flows work to clear all IRQ vectors, which would require
      us to use i40e_setup_misc_vector() directly. Since during this time the
      __I40E_RECOVERY_PENDING bit is set, we'll never re-allocate the vector.
      
      Rather than leaving the open-coded setup in i40e_resume() lets just fix
      the problem properly in i40e_setup_misc_vector().
      
      Introduce a new state bit which indicates when the IRQ has been
      assigned, which will be set when i40e_setup_misc_vector is first called.
      This ultimately resolves the issue of re-requesting the vector, without
      overloading the __I40E_RECOVERY_PENDING state. This ensures that the
      suspend/resume cycle can use the setup function instead of open-coding
      the re-request during resume.
      
      Additionally, since the only callers of i40e_stop_misc_vector also want
      to free it, move this code directly into the function to avoid
      duplication. Due to the new functionality, rename it to
      i40e_free_misc_vector().
      
      This lets us drop the extra calls to free and re-enable the vector
      during i40e_suspend() and i40e_resume(). We don't need to call
      i40e_setup_misc_Vector() in i40e_resume() because it gets called by the
      i40e_rebuild() call.
      Signed-off-by: default avatarJacob Keller <jacob.e.keller@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      c17401a1
    • Mitch Williams's avatar
      i40evf: lower message level · 905770fa
      Mitch Williams authored
      We see this message regularly on VF reset or unload (which invokes a
      reset). It's essentially meaningless unless it's happening constantly.
      To prevent consternation, lower the log level to debug so it's not seen
      under normal circumstance.
      Signed-off-by: default avatarMitch Williams <mitch.a.williams@intel.com>
      Tested-by: default avatarAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      905770fa