1. 31 Aug, 2015 28 commits
  2. 30 Aug, 2015 5 commits
  3. 29 Aug, 2015 7 commits
    • Jesse Gross's avatar
      geneve: Use GRO cells infrastructure. · 8e816df8
      Jesse Gross authored
      Geneve can benefit from GRO at the device level in a manner similar
      to other tunnels, especially as hardware offloads are still emerging.
      
      After this patch, aggregated frames are seen on the tunnel interface.
      Single stream throughput nearly doubles in ideal circumstances (on
      old hardware).
      Signed-off-by: default avatarJesse Gross <jesse@nicira.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e816df8
    • Simon Horman's avatar
      openvswitch: retain parsed IPv6 header fields in flow on error skipping extension headers · c30da497
      Simon Horman authored
      When an error occurs skipping IPv6 extension headers retain the already
      parsed IP protocol and IPv6 addresses in the flow. Also assume that the
      packet is not a fragment in the absence of information to the contrary;
      that is always use the frag_off value set by ipv6_skip_exthdr().
      
      This allows matching on the IP protocol and IPv6 addresses of packets
      with malformed extension headers.
      Signed-off-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c30da497
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · f5004a14
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2015-08-28
      
      One more bunch of Bluetooth patches for 4.3:
      
       - Crash fix for hci_bcm driver
       - Enhancements to hci_intel driver (e.g. baudrate configuration)
       - Fix for SCO link type after multiple connect attempts
       - Cleanups & minor fixes in a few other places
      
      Please let me know if there are any issues pulling. Thanks.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f5004a14
    • Tony Lindgren's avatar
      net/smsc911x: Fix deferred probe for interrupt · f892a84c
      Tony Lindgren authored
      The interrupt handler may not be available when smsc911x probes if the
      interrupt handler is a GPIO controller for example. Let's fix that
      by adding handling for -EPROBE_DEFER.
      
      Cc: Steve Glendinning <steve.glendinning@shawell.net>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f892a84c
    • David S. Miller's avatar
      Merge branch 'tnl-ipv4-ipv6' · 6d742324
      David S. Miller authored
      Jiri Benc says:
      
      ====================
      tunnels: fix incorrect IPv4/v6 headers interpretation
      
      With tunneling, it is currently possible to get an IPv6 header and interpret
      it as an IPv4 header, or to interpret an IPv6 address as an IPv4 address
      (and vice versa). This leads to things like sending packets to incorrect
      address, IPv6 flow label being interpreted as IP packet length, etc.
      
      Fix several places where this can happen.
      
      Most of this is net-next only. The third patch affects net, too, but it
      doesn't seem there's anything in user space that sets the attribute at all
      currently, thus net-next is fine.
      
      Changelog:
      v2: fixed geneve after incorrect rebase on top of Pravin's patches
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6d742324
    • Jiri Benc's avatar
      vxlan: do not receive IPv4 packets on IPv6 socket · a43a9ef6
      Jiri Benc authored
      By default (subject to the sysctl settings), IPv6 sockets listen also for
      IPv4 traffic. Vxlan is not prepared for that and expects IPv6 header in
      packets received through an IPv6 socket.
      
      In addition, it's currently not possible to have both IPv4 and IPv6 vxlan
      tunnel on the same port (unless bindv6only sysctl is enabled), as it's not
      possible to create and bind both IPv4 and IPv6 vxlan interfaces and there's
      no way to specify both IPv4 and IPv6 remote/group IP addresses.
      
      Set IPV6_V6ONLY on vxlan sockets to fix both of these issues. This is not
      done globally in udp_tunnel, as l2tp and tipc seems to work okay when
      receiving IPv4 packets on IPv6 socket and people may rely on this behavior.
      The other tunnels (geneve and fou) do not support IPv6.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a43a9ef6
    • Jiri Benc's avatar
      fou: reject IPv6 config · b9b6695c
      Jiri Benc authored
      fou does not really support IPv6 encapsulation. After an UDP socket is
      created in fou_create, the encap_rcv callback is set either to fou_udp_recv
      or to gue_udp_recv. Both of those unconditionally assume that the received
      packet has an IPv4 header and access the data at network_header as it was an
      IPv4 header. This leads to IPv6 flow label being interpreted as IP packet
      length, etc.
      
      Disallow fou tunnel to be configured as IPv6 until real IPv6 support is
      added to fou.
      
      CC: Tom Herbert <tom@herbertland.com>
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b9b6695c