1. 18 Sep, 2015 1 commit
  2. 11 Aug, 2015 1 commit
  3. 18 May, 2015 1 commit
  4. 05 May, 2015 2 commits
  5. 23 Apr, 2015 3 commits
  6. 12 Feb, 2015 1 commit
  7. 13 Nov, 2014 2 commits
    • Herbert Xu's avatar
      xfrm: Use __xfrm_policy_link in xfrm_policy_insert · 12bfa8bd
      Herbert Xu authored
      
      
      For a long time we couldn't actually use __xfrm_policy_link in
      xfrm_policy_insert because the latter wanted to do hashing at
      a specific position.
      
      Now that __xfrm_policy_link no longer does hashing it can now
      be safely used in xfrm_policy_insert to kill some duplicate code,
      finally reuniting general policies with socket policies.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      12bfa8bd
    • Herbert Xu's avatar
      xfrm: Do not hash socket policies · 53c2e285
      Herbert Xu authored
      
      
      Back in 2003 when I added policy expiration, I half-heartedly
      did a clean-up and renamed xfrm_sk_policy_link/xfrm_sk_policy_unlink
      to __xfrm_policy_link/__xfrm_policy_unlink, because the latter
      could be reused for all policies.  I never actually got around
      to using __xfrm_policy_link for non-socket policies.
      
      Later on hashing was added to all xfrm policies, including socket
      policies.  In fact, we don't need hashing on socket policies at
      all since they're always looked up via a linked list.
      
      This patch restores xfrm_sk_policy_link/xfrm_sk_policy_unlink
      as wrappers around __xfrm_policy_link/__xfrm_policy_unlink so
      that it's obvious we're dealing with socket policies.
      
      This patch also removes hashing from __xfrm_policy_link as for
      now it's only used by socket policies which do not need to be
      hashed.  Ironically this will in fact allow us to use this helper
      for non-socket policies which I shall do later.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      53c2e285
  8. 30 Oct, 2014 1 commit
  9. 27 Oct, 2014 1 commit
  10. 01 Oct, 2014 1 commit
  11. 16 Sep, 2014 2 commits
  12. 02 Sep, 2014 2 commits
    • Christophe Gouault's avatar
      xfrm: configure policy hash table thresholds by netlink · 880a6fab
      Christophe Gouault authored
      
      
      Enable to specify local and remote prefix length thresholds for the
      policy hash table via a netlink XFRM_MSG_NEWSPDINFO message.
      
      prefix length thresholds are specified by XFRMA_SPD_IPV4_HTHRESH and
      XFRMA_SPD_IPV6_HTHRESH optional attributes (struct xfrmu_spdhthresh).
      
      example:
      
          struct xfrmu_spdhthresh thresh4 = {
              .lbits = 0;
              .rbits = 24;
          };
          struct xfrmu_spdhthresh thresh6 = {
              .lbits = 0;
              .rbits = 56;
          };
          struct nlmsghdr *hdr;
          struct nl_msg *msg;
      
          msg = nlmsg_alloc();
          hdr = nlmsg_put(msg, NL_AUTO_PORT, NL_AUTO_SEQ, XFRMA_SPD_IPV4_HTHRESH, sizeof(__u32), NLM_F_REQUEST);
          nla_put(msg, XFRMA_SPD_IPV4_HTHRESH, sizeof(thresh4), &thresh4);
          nla_put(msg, XFRMA_SPD_IPV6_HTHRESH, sizeof(thresh6), &thresh6);
          nla_send_auto(sk, msg);
      
      The numbers are the policy selector minimum prefix lengths to put a
      policy in the hash table.
      
      - lbits is the local threshold (source address for out policies,
        destination address for in and fwd policies).
      
      - rbits is the remote threshold (destination address for out
        policies, source address for in and fwd policies).
      
      The default values are:
      
      XFRMA_SPD_IPV4_HTHRESH: 32 32
      XFRMA_SPD_IPV6_HTHRESH: 128 128
      
      Dynamic re-building of the SPD is performed when the thresholds values
      are changed.
      
      The current thresholds can be read via a XFRM_MSG_GETSPDINFO request:
      the kernel replies to XFRM_MSG_GETSPDINFO requests by an
      XFRM_MSG_NEWSPDINFO message, with both attributes
      XFRMA_SPD_IPV4_HTHRESH and XFRMA_SPD_IPV6_HTHRESH.
      
      Signed-off-by: default avatarChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      880a6fab
    • Christophe Gouault's avatar
      xfrm: hash prefixed policies based on preflen thresholds · b58555f1
      Christophe Gouault authored
      
      
      The idea is an extension of the current policy hashing.
      
      Today only non-prefixed policies are stored in a hash table. This
      patch relaxes the constraints, and hashes policies whose prefix
      lengths are greater or equal to a configurable threshold.
      
      Each hash table (one per direction) maintains its own set of IPv4 and
      IPv6 thresholds (dbits4, sbits4, dbits6, sbits6), by default (32, 32,
      128, 128).
      
      Example, if the output hash table is configured with values (16, 24,
      56, 64):
      
      ip xfrm policy add dir out src 10.22.0.0/20 dst 10.24.1.0/24 ... => hashed
      ip xfrm policy add dir out src 10.22.0.0/16 dst 10.24.1.1/32 ... => hashed
      ip xfrm policy add dir out src 10.22.0.0/16 dst 10.24.0.0/16 ... => unhashed
      
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/60 dst 3ffe:304:124:2401::/64 ...    => hashed
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/56 dst 3ffe:304:124:2401::2/128 ...  => hashed
      ip xfrm policy add dir out \
          src 3ffe:304:124:2200::/56 dst 3ffe:304:124:2400::/56 ...    => unhashed
      
      The high order bits of the addresses (up to the threshold) are used to
      compute the hash key.
      
      Signed-off-by: default avatarChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      b58555f1
  13. 07 Aug, 2014 1 commit
    • Ken Helias's avatar
      list: fix order of arguments for hlist_add_after(_rcu) · 1d023284
      Ken Helias authored
      
      
      All other add functions for lists have the new item as first argument
      and the position where it is added as second argument.  This was changed
      for no good reason in this function and makes using it unnecessary
      confusing.
      
      The name was changed to hlist_add_behind() to cause unconverted code to
      generate a compile error instead of using the wrong parameter order.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarKen Helias <kenhelias@firemail.de>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>	[intel driver bits]
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1d023284
  14. 26 Jun, 2014 1 commit
  15. 07 May, 2014 1 commit
    • WANG Cong's avatar
      net: clean up snmp stats code · 698365fa
      WANG Cong authored
      commit 8f0ea0fe (snmp: reduce percpu needs by 50%)
      reduced snmp array size to 1, so technically it doesn't have to be
      an array any more. What's more, after the following commit:
      
      	commit 933393f5
      
      
      	Date:   Thu Dec 22 11:58:51 2011 -0600
      
      	    percpu: Remove irqsafe_cpu_xxx variants
      
      	    We simply say that regular this_cpu use must be safe regardless of
      	    preemption and interrupt state.  That has no material change for x86
      	    and s390 implementations of this_cpu operations.  However, arches that
      	    do not provide their own implementation for this_cpu operations will
      	    now get code generated that disables interrupts instead of preemption.
      
      probably no arch wants to have SNMP_ARRAY_SZ == 2. At least after
      almost 3 years, no one complains.
      
      So, just convert the array to a single pointer and remove snmp_mib_init()
      and snmp_mib_free() as well.
      
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      698365fa
  16. 23 Apr, 2014 1 commit
  17. 22 Apr, 2014 1 commit
    • Tetsuo Handa's avatar
      xfrm: Remove useless secid field from xfrm_audit. · f1370cc4
      Tetsuo Handa authored
      It seems to me that commit ab5f5e8b
      
       "[XFRM]: xfrm audit calls" is doing
      something strange at xfrm_audit_helper_usrinfo().
      If secid != 0 && security_secid_to_secctx(secid) != 0, the caller calls
      audit_log_task_context() which basically does
      secid != 0 && security_secid_to_secctx(secid) == 0 case
      except that secid is obtained from current thread's context.
      
      Oh, what happens if secid passed to xfrm_audit_helper_usrinfo() was
      obtained from other thread's context? It might audit current thread's
      context rather than other thread's context if security_secid_to_secctx()
      in xfrm_audit_helper_usrinfo() failed for some reason.
      
      Then, are all the caller of xfrm_audit_helper_usrinfo() passing either
      secid obtained from current thread's context or secid == 0?
      It seems to me that they are.
      
      If I didn't miss something, we don't need to pass secid to
      xfrm_audit_helper_usrinfo() because audit_log_task_context() will
      obtain secid from current thread's context.
      
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      f1370cc4
  18. 15 Apr, 2014 1 commit
  19. 12 Mar, 2014 1 commit
  20. 26 Feb, 2014 1 commit
  21. 19 Feb, 2014 1 commit
  22. 12 Feb, 2014 1 commit
    • Fan Du's avatar
      flowcache: Make flow cache name space aware · ca925cf1
      Fan Du authored
      
      
      Inserting a entry into flowcache, or flushing flowcache should be based
      on per net scope. The reason to do so is flushing operation from fat
      netns crammed with flow entries will also making the slim netns with only
      a few flow cache entries go away in original implementation.
      
      Since flowcache is tightly coupled with IPsec, so it would be easier to
      put flow cache global parameters into xfrm namespace part. And one last
      thing needs to do is bumping flow cache genid, and flush flow cache should
      also be made in per net style.
      
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      ca925cf1
  23. 14 Jan, 2014 1 commit
  24. 08 Jan, 2014 1 commit
  25. 07 Jan, 2014 1 commit
  26. 02 Jan, 2014 5 commits
  27. 06 Dec, 2013 4 commits