1. 03 10月, 2017 5 次提交
  2. 02 10月, 2017 14 次提交
  3. 01 10月, 2017 16 次提交
  4. 30 9月, 2017 5 次提交
    • C
      mkiss: remove redundant check on len being zero · 45c1fd61
      Colin Ian King 提交于
      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: NColin Ian King <colin.king@canonical.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45c1fd61
    • M
      net-ipv6: add support for sockopt(SOL_IPV6, IPV6_FREEBIND) · 84e14fe3
      Maciej Żenczykowski 提交于
      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: NMaciej Żenczykowski <maze@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84e14fe3
    • M
      net: ipv6: send NS for DAD when link operationally up · 1f372c7b
      Mike Manning 提交于
      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: NMike Manning <mmanning@brocade.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1f372c7b
    • M
      i40e: refactor FW version checking · 22b96551
      Mitch Williams 提交于
      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: NMitch Williams <mitch.a.williams@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      22b96551
    • A
      i40e: Enable VF to negotiate number of allocated queues · a3f5aa90
      Alan Brady 提交于
      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: NAlan Brady <alan.brady@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      a3f5aa90