1. 11 8月, 2017 1 次提交
    • L
      net: xfrm: support setting an output mark. · 077fbac4
      Lorenzo Colitti 提交于
      On systems that use mark-based routing it may be necessary for
      routing lookups to use marks in order for packets to be routed
      correctly. An example of such a system is Android, which uses
      socket marks to route packets via different networks.
      
      Currently, routing lookups in tunnel mode always use a mark of
      zero, making routing incorrect on such systems.
      
      This patch adds a new output_mark element to the xfrm state and
      a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
      mark differs from the existing xfrm mark in two ways:
      
      1. The xfrm mark is used to match xfrm policies and states, while
         the xfrm output mark is used to set the mark (and influence
         the routing) of the packets emitted by those states.
      2. The existing mark is constrained to be a subset of the bits of
         the originating socket or transformed packet, but the output
         mark is arbitrary and depends only on the state.
      
      The use of a separate mark provides additional flexibility. For
      example:
      
      - A packet subject to two transforms (e.g., transport mode inside
        tunnel mode) can have two different output marks applied to it,
        one for the transport mode SA and one for the tunnel mode SA.
      - On a system where socket marks determine routing, the packets
        emitted by an IPsec tunnel can be routed based on a mark that
        is determined by the tunnel, not by the marks of the
        unencrypted packets.
      - Support for setting the output marks can be introduced without
        breaking any existing setups that employ both mark-based
        routing and xfrm tunnel mode. Simply changing the code to use
        the xfrm mark for routing output packets could xfrm mark could
        change behaviour in a way that breaks these setups.
      
      If the output mark is unspecified or set to zero, the mark is not
      set or changed.
      
      Tested: make allyesconfig; make -j64
      Tested: https://android-review.googlesource.com/452776Signed-off-by: NLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      077fbac4
  2. 19 7月, 2017 2 次提交
  3. 09 2月, 2017 3 次提交
  4. 11 9月, 2016 1 次提交
  5. 22 8月, 2016 1 次提交
  6. 17 6月, 2016 1 次提交
    • A
      net: xfrm: fix old-style declaration · 318d3cc0
      Arnd Bergmann 提交于
      Modern C standards expect the '__inline__' keyword to come before the return
      type in a declaration, and we get a couple of warnings for this with "make W=1"
      in the xfrm{4,6}_policy.c files:
      
      net/ipv6/xfrm6_policy.c:369:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration]
       static int inline xfrm6_net_sysctl_init(struct net *net)
      net/ipv6/xfrm6_policy.c:374:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration]
       static void inline xfrm6_net_sysctl_exit(struct net *net)
      net/ipv4/xfrm4_policy.c:339:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration]
       static int inline xfrm4_net_sysctl_init(struct net *net)
      net/ipv4/xfrm4_policy.c:344:1: error: 'inline' is not at beginning of declaration [-Werror=old-style-declaration]
       static void inline xfrm4_net_sysctl_exit(struct net *net)
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      318d3cc0
  7. 03 11月, 2015 1 次提交
    • D
      xfrm: dst_entries_init() per-net dst_ops · a8a572a6
      Dan Streetman 提交于
      Remove the dst_entries_init/destroy calls for xfrm4 and xfrm6 dst_ops
      templates; their dst_entries counters will never be used.  Move the
      xfrm dst_ops initialization from the common xfrm/xfrm_policy.c to
      xfrm4/xfrm4_policy.c and xfrm6/xfrm6_policy.c, and call dst_entries_init
      and dst_entries_destroy for each net namespace.
      
      The ipv4 and ipv6 xfrms each create dst_ops template, and perform
      dst_entries_init on the templates.  The template values are copied to each
      net namespace's xfrm.xfrm*_dst_ops.  The problem there is the dst_ops
      pcpuc_entries field is a percpu counter and cannot be used correctly by
      simply copying it to another object.
      
      The result of this is a very subtle bug; changes to the dst entries
      counter from one net namespace may sometimes get applied to a different
      net namespace dst entries counter.  This is because of how the percpu
      counter works; it has a main count field as well as a pointer to the
      percpu variables.  Each net namespace maintains its own main count
      variable, but all point to one set of percpu variables.  When any net
      namespace happens to change one of the percpu variables to outside its
      small batch range, its count is moved to the net namespace's main count
      variable.  So with multiple net namespaces operating concurrently, the
      dst_ops entries counter can stray from the actual value that it should
      be; if counts are consistently moved from one net namespace to another
      (which my testing showed is likely), then one net namespace winds up
      with a negative dst_ops count while another winds up with a continually
      increasing count, eventually reaching its gc_thresh limit, which causes
      all new traffic on the net namespace to fail with -ENOBUFS.
      Signed-off-by: NDan Streetman <dan.streetman@canonical.com>
      Signed-off-by: NDan Streetman <ddstreet@ieee.org>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      a8a572a6
  8. 23 10月, 2015 2 次提交
  9. 08 10月, 2015 2 次提交
  10. 30 9月, 2015 1 次提交
  11. 29 9月, 2015 1 次提交
    • S
      xfrm: Let the flowcache handle its size by default. · c386578f
      Steffen Klassert 提交于
      The xfrm flowcache size is limited by the flowcache limit
      (4096 * number of online cpus) and the xfrm garbage collector
      threshold (2 * 32768), whatever is reached first. This means
      that we can hit the garbage collector limit only on systems
      with more than 16 cpus. On such systems we simply refuse
      new allocations if we reach the limit, so new flows are dropped.
      On syslems with 16 or less cpus, we hit the flowcache limit.
      In this case, we shrink the flow cache instead of refusing new
      flows.
      
      We increase the xfrm garbage collector threshold to INT_MAX
      to get the same behaviour, independent of the number of cpus.
      
      The xfrm garbage collector threshold can still be set below
      the flowcache limit to reduce the memory usage of the flowcache.
      Tested-by: NDan Streetman <dan.streetman@canonical.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      c386578f
  12. 18 9月, 2015 1 次提交
  13. 16 9月, 2015 1 次提交
  14. 26 8月, 2015 1 次提交
  15. 11 8月, 2015 1 次提交
  16. 04 4月, 2015 1 次提交
  17. 10 3月, 2015 1 次提交
  18. 14 3月, 2014 1 次提交
  19. 01 11月, 2013 1 次提交
  20. 28 10月, 2013 1 次提交
    • S
      xfrm: Increase the garbage collector threshold · eeb1b733
      Steffen Klassert 提交于
      With the removal of the routing cache, we lost the
      option to tweak the garbage collector threshold
      along with the maximum routing cache size. So git
      commit 703fb94e ("xfrm: Fix the gc threshold value
      for ipv4") moved back to a static threshold.
      
      It turned out that the current threshold before we
      start garbage collecting is much to small for some
      workloads, so increase it from 1024 to 32768. This
      means that we start the garbage collector if we have
      more than 32768 dst entries in the system and refuse
      new allocations if we are above 65536.
      Reported-by: NWolfgang Walter <linux@stwm.de>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      eeb1b733
  21. 16 9月, 2013 1 次提交
  22. 06 2月, 2013 2 次提交
  23. 13 11月, 2012 1 次提交
  24. 09 10月, 2012 1 次提交
    • J
      ipv4: introduce rt_uses_gateway · 155e8336
      Julian Anastasov 提交于
      Add new flag to remember when route is via gateway.
      We will use it to allow rt_gateway to contain address of
      directly connected host for the cases when DST_NOCACHE is
      used or when the NH exception caches per-destination route
      without DST_NOCACHE flag, i.e. when routes are not used for
      other destinations. By this way we force the neighbour
      resolving to work with the routed destination but we
      can use different address in the packet, feature needed
      for IPVS-DR where original packet for virtual IP is routed
      via route to real IP.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      155e8336
  25. 01 8月, 2012 1 次提交
  26. 21 7月, 2012 6 次提交
  27. 17 7月, 2012 1 次提交
    • D
      net: Pass optional SKB and SK arguments to dst_ops->{update_pmtu,redirect}() · 6700c270
      David S. Miller 提交于
      This will be used so that we can compose a full flow key.
      
      Even though we have a route in this context, we need more.  In the
      future the routes will be without destination address, source address,
      etc. keying.  One ipv4 route will cover entire subnets, etc.
      
      In this environment we have to have a way to possess persistent storage
      for redirects and PMTU information.  This persistent storage will exist
      in the FIB tables, and that's why we'll need to be able to rebuild a
      full lookup flow key here.  Using that flow key will do a fib_lookup()
      and create/update the persistent entry.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6700c270
  28. 12 7月, 2012 2 次提交