1. 26 Apr, 2017 1 commit
    • Xin Long's avatar
      xfrm: do the garbage collection after flushing policy · 35db0691
      Xin Long authored
      Now xfrm garbage collection can be triggered by 'ip xfrm policy del'.
      These is no reason not to do it after flushing policies, especially
      considering that 'garbage collection deferred' is only triggered
      when it reaches gc_thresh.
      It's no good that the policy is gone but the xdst still hold there.
      The worse thing is that xdst->route/orig_dst is also hold and can
      not be released even if the orig_dst is already expired.
      This patch is to do the garbage collection if there is any policy
      removed in xfrm_policy_flush.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
  2. 27 Feb, 2017 1 commit
  3. 14 Feb, 2017 1 commit
  4. 09 Feb, 2017 7 commits
  5. 07 Feb, 2017 1 commit
  6. 04 Jan, 2017 1 commit
  7. 18 Nov, 2016 1 commit
  8. 09 Nov, 2016 1 commit
  9. 24 Aug, 2016 1 commit
  10. 12 Aug, 2016 8 commits
  11. 29 Jul, 2016 1 commit
    • Tobias Brunner's avatar
      xfrm: Ignore socket policies when rebuilding hash tables · 6916fb3b
      Tobias Brunner authored
      Whenever thresholds are changed the hash tables are rebuilt.  This is
      done by enumerating all policies and hashing and inserting them into
      the right table according to the thresholds and direction.
      Because socket policies are also contained in net->xfrm.policy_all but
      no hash tables are defined for their direction (dir + XFRM_POLICY_MAX)
      this causes a NULL or invalid pointer dereference after returning from
      policy_hash_bysel() if the rebuild is done while any socket policies
      are installed.
      Since the rebuild after changing thresholds is scheduled this crash
      could even occur if the userland sets thresholds seemingly before
      installing any socket policies.
      Fixes: 53c2e285
       ("xfrm: Do not hash socket policies")
      Signed-off-by: default avatarTobias Brunner <tobias@strongswan.org>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
  12. 12 Dec, 2015 2 commits
  13. 07 Dec, 2015 1 commit
  14. 03 Nov, 2015 1 commit
    • Dan Streetman's avatar
      xfrm: dst_entries_init() per-net dst_ops · a8a572a6
      Dan Streetman authored
      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: default avatarDan Streetman <dan.streetman@canonical.com>
      Signed-off-by: default avatarDan Streetman <ddstreet@ieee.org>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
  15. 08 Oct, 2015 3 commits
  16. 25 Sep, 2015 1 commit
  17. 18 Sep, 2015 2 commits
  18. 11 Aug, 2015 1 commit
  19. 18 May, 2015 1 commit
  20. 05 May, 2015 2 commits
  21. 23 Apr, 2015 2 commits