1. 27 6月, 2017 1 次提交
  2. 16 6月, 2017 1 次提交
    • J
      networking: make skb_push & __skb_push return void pointers · d58ff351
      Johannes Berg 提交于
      It seems like a historic accident that these return unsigned char *,
      and in many places that means casts are required, more often than not.
      
      Make these functions return void * and remove all the casts across
      the tree, adding a (u8 *) cast only where the unsigned char pointer
      was used directly, all done with the following spatch:
      
          @@
          expression SKB, LEN;
          typedef u8;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - *(fn(SKB, LEN))
          + *(u8 *)fn(SKB, LEN)
      
          @@
          expression E, SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          type T;
          @@
          - E = ((T *)(fn(SKB, LEN)))
          + E = fn(SKB, LEN)
      
          @@
          expression SKB, LEN;
          identifier fn = { skb_push, __skb_push, skb_push_rcsum };
          @@
          - fn(SKB, LEN)[0]
          + *(u8 *)fn(SKB, LEN)
      
      Note that the last part there converts from push(...)[0] to the
      more idiomatic *(u8 *)push(...).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d58ff351
  3. 22 4月, 2017 1 次提交
    • C
      ip_tunnel: Allow policy-based routing through tunnels · 9830ad4c
      Craig Gallek 提交于
      This feature allows the administrator to set an fwmark for
      packets traversing a tunnel.  This allows the use of independent
      routing tables for tunneled packets without the use of iptables.
      
      There is no concept of per-packet routing decisions through IPv4
      tunnels, so this implementation does not need to work with
      per-packet route lookups as the v6 implementation may
      (with IP6_TNL_F_USE_ORIG_FWMARK).
      
      Further, since the v4 tunnel ioctls share datastructures
      (which can not be trivially modified) with the kernel's internal
      tunnel configuration structures, the mark attribute must be stored
      in the tunnel structure itself and passed as a parameter when
      creating or changing tunnel attributes.
      Signed-off-by: NCraig Gallek <kraig@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9830ad4c
  4. 25 12月, 2016 1 次提交
  5. 18 11月, 2016 1 次提交
    • A
      netns: make struct pernet_operations::id unsigned int · c7d03a00
      Alexey Dobriyan 提交于
      Make struct pernet_operations::id unsigned.
      
      There are 2 reasons to do so:
      
      1)
      This field is really an index into an zero based array and
      thus is unsigned entity. Using negative value is out-of-bound
      access by definition.
      
      2)
      On x86_64 unsigned 32-bit data which are mixed with pointers
      via array indexing or offsets added or subtracted to pointers
      are preffered to signed 32-bit data.
      
      "int" being used as an array index needs to be sign-extended
      to 64-bit before being used.
      
      	void f(long *p, int i)
      	{
      		g(p[i]);
      	}
      
        roughly translates to
      
      	movsx	rsi, esi
      	mov	rdi, [rsi+...]
      	call 	g
      
      MOVSX is 3 byte instruction which isn't necessary if the variable is
      unsigned because x86_64 is zero extending by default.
      
      Now, there is net_generic() function which, you guessed it right, uses
      "int" as an array index:
      
      	static inline void *net_generic(const struct net *net, int id)
      	{
      		...
      		ptr = ng->ptr[id - 1];
      		...
      	}
      
      And this function is used a lot, so those sign extensions add up.
      
      Patch snipes ~1730 bytes on allyesconfig kernel (without all junk
      messing with code generation):
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      
      Unfortunately some functions actually grow bigger.
      This is a semmingly random artefact of code generation with register
      allocator being used differently. gcc decides that some variable
      needs to live in new r8+ registers and every access now requires REX
      prefix. Or it is shifted into r12, so [r12+0] addressing mode has to be
      used which is longer than [r8]
      
      However, overall balance is in negative direction:
      
      	add/remove: 0/0 grow/shrink: 70/598 up/down: 396/-2126 (-1730)
      	function                                     old     new   delta
      	nfsd4_lock                                  3886    3959     +73
      	tipc_link_build_proto_msg                   1096    1140     +44
      	mac80211_hwsim_new_radio                    2776    2808     +32
      	tipc_mon_rcv                                1032    1058     +26
      	svcauth_gss_legacy_init                     1413    1429     +16
      	tipc_bcbase_select_primary                   379     392     +13
      	nfsd4_exchange_id                           1247    1260     +13
      	nfsd4_setclientid_confirm                    782     793     +11
      		...
      	put_client_renew_locked                      494     480     -14
      	ip_set_sockfn_get                            730     716     -14
      	geneve_sock_add                              829     813     -16
      	nfsd4_sequence_done                          721     703     -18
      	nlmclnt_lookup_host                          708     686     -22
      	nfsd4_lockt                                 1085    1063     -22
      	nfs_get_client                              1077    1050     -27
      	tcf_bpf_init                                1106    1076     -30
      	nfsd4_encode_fattr                          5997    5930     -67
      	Total: Before=154856051, After=154854321, chg -0.00%
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c7d03a00
  6. 11 9月, 2016 1 次提交
  7. 16 8月, 2016 1 次提交
  8. 19 6月, 2016 2 次提交
    • E
      ipv6: RFC 4884 partial support for SIT/GRE tunnels · 20e1954f
      Eric Dumazet 提交于
      When receiving an ICMPv4 message containing extensions as
      defined in RFC 4884, and translating it to ICMPv6 at SIT
      or GRE tunnel, we need some extra manipulation in order
      to properly forward the extensions.
      
      This patch only takes care of Time Exceeded messages as they
      are the ones that typically carry information from various
      routers in a fabric during a traceroute session.
      
      It also avoids complex skb logic if the data_len is not
      a multiple of 8.
      
      RFC states :
      
         The "original datagram" field MUST contain at least 128 octets.
         If the original datagram did not contain 128 octets, the
         "original datagram" field MUST be zero padded to 128 octets.
      
      In practice routers use 128 bytes of original datagram, not more.
      
      Initial translation was added in commit ca15a078
      ("sit: generate icmpv6 error when receiving icmpv4 error")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Oussama Ghorbel <ghorbel@pivasoftware.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      20e1954f
    • E
      gre: better support for ICMP messages for gre+ipv6 · 9b8c6d7b
      Eric Dumazet 提交于
      ipgre_err() can call ip6_err_gen_icmpv6_unreach() for proper
      support of ipv4+gre+icmp+ipv6+... frames, used for example
      by traceroute/mtr.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9b8c6d7b
  9. 16 6月, 2016 2 次提交
    • E
      gre: fix error handler · e582615a
      Eric Dumazet 提交于
      1) gre_parse_header() can be called from gre_err()
      
         At this point transport header points to ICMP header, not the inner
      header.
      
      2) We can not really change transport header as ipgre_err() will later
      assume transport header still points to ICMP header (using icmp_hdr())
      
      3) pskb_may_pull() logic in gre_parse_header() really works
        if we are interested at zone pointed by skb->data
      
      4) As Jiri explained in commit b7f8fe25 ("gre: do not pull header in
      ICMP error processing") we should not pull headers in error handler.
      
      So this fix :
      
      A) changes gre_parse_header() to use skb->data instead of
      skb_transport_header()
      
      B) Adds a nhs parameter to gre_parse_header() so that we can skip the
      not pulled IP header from error path.
        This offset is 0 for normal receive path.
      
      C) remove obsolete IPV6 includes
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Tom Herbert <tom@herbertland.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Jiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e582615a
    • P
      net: ipv4: Add ability to have GRE ignore DF bit in IPv4 payloads · 22a59be8
      Philip Prindeville 提交于
          In the presence of firewalls which improperly block ICMP Unreachable
          (including Fragmentation Required) messages, Path MTU Discovery is
          prevented from working.
      
          A workaround is to handle IPv4 payloads opaquely, ignoring the DF bit--as
          is done for other payloads like AppleTalk--and doing transparent
          fragmentation and reassembly.
      
          Redux includes the enforcement of mutual exclusion between this feature
          and Path MTU Discovery as suggested by Alexander Duyck.
      
          Cc: Alexander Duyck <alexander.duyck@gmail.com>
      Reviewed-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NPhilip Prindeville <philipp@redfish-solutions.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22a59be8
  10. 15 6月, 2016 2 次提交
  11. 13 5月, 2016 1 次提交
  12. 12 5月, 2016 1 次提交
    • J
      gre: do not keep the GRE header around in collect medata mode · e271c7b4
      Jiri Benc 提交于
      For ipgre interface in collect metadata mode, it doesn't make sense for the
      interface to be of ARPHRD_IPGRE type. The outer header of received packets
      is not needed, as all the information from it is present in metadata_dst. We
      already don't set ipgre_header_ops for collect metadata interfaces, which is
      the only consumer of mac_header pointing to the outer IP header.
      
      Just set the interface type to ARPHRD_NONE in collect metadata mode for
      ipgre (not gretap, that still correctly stays ARPHRD_ETHER) and reset
      mac_header.
      
      Fixes: a64b04d8 ("gre: do not assign header_ops in collect metadata mode")
      Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e271c7b4
  13. 05 5月, 2016 3 次提交
  14. 03 5月, 2016 2 次提交
  15. 02 5月, 2016 1 次提交
    • J
      gre: do not pull header in ICMP error processing · b7f8fe25
      Jiri Benc 提交于
      iptunnel_pull_header expects that IP header was already pulled; with this
      expectation, it pulls the tunnel header. This is not true in gre_err.
      Furthermore, ipv4_update_pmtu and ipv4_redirect expect that skb->data points
      to the IP header.
      
      We cannot pull the tunnel header in this path. It's just a matter of not
      calling iptunnel_pull_header - we don't need any of its effects.
      
      Fixes: bda7bb46 ("gre: Allow multiple protocol listener for gre protocol.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7f8fe25
  16. 29 4月, 2016 3 次提交
    • J
      gre: reject GUE and FOU in collect metadata mode · 946b636f
      Jiri Benc 提交于
      The collect metadata mode does not support GUE nor FOU. This might be
      implemented later; until then, we should reject such config.
      
      I think this is okay to be changed. It's unlikely anyone has such
      configuration (as it doesn't work anyway) and we may need a way to
      distinguish whether it's supported or not by the kernel later.
      
      For backwards compatibility with iproute2, it's not possible to just check
      the attribute presence (iproute2 always includes the attribute), the actual
      value has to be checked, too.
      
      Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      946b636f
    • J
      gre: build header correctly for collect metadata tunnels · 2090714e
      Jiri Benc 提交于
      In ipgre (i.e. not gretap) + collect metadata mode, the skb was assumed to
      contain Ethernet header and was encapsulated as ETH_P_TEB. This is not the
      case, the interface is ARPHRD_IPGRE and the protocol to be used for
      encapsulation is skb->protocol.
      
      Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NPravin B Shelar <pshelar@ovn.org>
      Reviewed-by: NSimon Horman <simon.horman@netronome.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2090714e
    • J
      gre: do not assign header_ops in collect metadata mode · a64b04d8
      Jiri Benc 提交于
      In ipgre mode (i.e. not gretap) with collect metadata flag set, the tunnel
      is incorrectly assumed to be mGRE in NBMA mode (see commit 6a5f44d7).
      This is not the case, we're controlling the encapsulation addresses by
      lwtunnel metadata. And anyway, assigning dev->header_ops in collect metadata
      mode does not make sense.
      
      Although it would be more user firendly to reject requests that specify
      both the collect metadata flag and a remote/local IP address, this would
      break current users of gretap or introduce ugly code and differences in
      handling ipgre and gretap configuration. Keep the current behavior of
      remote/local IP address being ignored in such case.
      
      v3: Back to v1, added explanation paragraph.
      v2: Reject configuration specifying both remote/local address and collect
          metadata flag.
      
      Fixes: 2e15ea39 ("ip_gre: Add support to collect tunnel metadata.")
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a64b04d8
  17. 17 4月, 2016 1 次提交
  18. 08 4月, 2016 1 次提交
    • A
      GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU · a0ca153f
      Alexander Duyck 提交于
      This patch fixes an issue I found in which we were dropping frames if we
      had enabled checksums on GRE headers that were encapsulated by either FOU
      or GUE.  Without this patch I was barely able to get 1 Gb/s of throughput.
      With this patch applied I am now at least getting around 6 Gb/s.
      
      The issue is due to the fact that with FOU or GUE applied we do not provide
      a transport offset pointing to the GRE header, nor do we offload it in
      software as the GRE header is completely skipped by GSO and treated like a
      VXLAN or GENEVE type header.  As such we need to prevent the stack from
      generating it and also prevent GRE from generating it via any interface we
      create.
      
      Fixes: c3483384 ("gro: Allow tunnel stacking in the case of FOU/GUE")
      Signed-off-by: NAlexander Duyck <aduyck@mirantis.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0ca153f
  19. 09 3月, 2016 1 次提交
    • D
      bpf, vxlan, geneve, gre: fix usage of dst_cache on xmit · db3c6139
      Daniel Borkmann 提交于
      The assumptions from commit 0c1d70af ("net: use dst_cache for vxlan
      device"), 468dfffc ("geneve: add dst caching support") and 3c1cb4d2
      ("net/ipv4: add dst cache support for gre lwtunnels") on dst_cache usage
      when ip_tunnel_info is used is unfortunately not always valid as assumed.
      
      While it seems correct for ip_tunnel_info front-ends such as OVS, eBPF
      however can fill in ip_tunnel_info for consumers like vxlan, geneve or gre
      with different remote dsts, tos, etc, therefore they cannot be assumed as
      packet independent.
      
      Right now vxlan, geneve, gre would cache the dst for eBPF and every packet
      would reuse the same entry that was first created on the initial route
      lookup. eBPF doesn't store/cache the ip_tunnel_info, so each skb may have
      a different one.
      
      Fix it by adding a flag that checks the ip_tunnel_info. Also the !tos test
      in vxlan needs to be handeled differently in this context as it is currently
      inferred from ip_tunnel_info as well if present. ip_tunnel_dst_cache_usable()
      helper is added for the three tunnel cases, which checks if we can use dst
      cache.
      
      Fixes: 0c1d70af ("net: use dst_cache for vxlan device")
      Fixes: 468dfffc ("geneve: add dst caching support")
      Fixes: 3c1cb4d2 ("net/ipv4: add dst cache support for gre lwtunnels")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db3c6139
  20. 19 2月, 2016 2 次提交
  21. 17 2月, 2016 1 次提交
  22. 12 2月, 2016 2 次提交
  23. 10 2月, 2016 1 次提交
    • D
      vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices · 7e059158
      David Wragg 提交于
      Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
      transmit vxlan packets of any size, constrained only by the ability to
      send out the resulting packets.  4.3 introduced netdevs corresponding
      to tunnel vports.  These netdevs have an MTU, which limits the size of
      a packet that can be successfully encapsulated.  The default MTU
      values are low (1500 or less), which is awkwardly small in the context
      of physical networks supporting jumbo frames, and leads to a
      conspicuous change in behaviour for userspace.
      
      Instead, set the MTU on openvswitch-created netdevs to be the relevant
      maximum (i.e. the maximum IP packet size minus any relevant overhead),
      effectively restoring the behaviour prior to 4.3.
      Signed-off-by: NDavid Wragg <david@weave.works>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e059158
  24. 26 12月, 2015 1 次提交
  25. 01 12月, 2015 1 次提交
  26. 23 10月, 2015 1 次提交
    • P
      openvswitch: Fix egress tunnel info. · fc4099f1
      Pravin B Shelar 提交于
      While transitioning to netdev based vport we broke OVS
      feature which allows user to retrieve tunnel packet egress
      information for lwtunnel devices.  Following patch fixes it
      by introducing ndo operation to get the tunnel egress info.
      Same ndo operation can be used for lwtunnel devices and compat
      ovs-tnl-vport devices. So after adding such device operation
      we can remove similar operation from ovs-vport.
      
      Fixes: 614732ea ("openvswitch: Use regular VXLAN net_device device").
      Signed-off-by: NPravin B Shelar <pshelar@nicira.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc4099f1
  27. 30 8月, 2015 2 次提交
  28. 28 8月, 2015 1 次提交
  29. 21 8月, 2015 1 次提交