1. 27 Apr, 2016 2 commits
  2. 11 Dec, 2015 2 commits
  3. 08 Oct, 2015 1 commit
  4. 17 Sep, 2015 1 commit
  5. 11 Aug, 2015 1 commit
  6. 27 May, 2015 2 commits
  7. 07 Apr, 2015 1 commit
    • David Miller's avatar
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      David Miller authored
      On the output paths in particular, we have to sometimes deal with two
      socket contexts.  First, and usually skb->sk, is the local socket that
      generated the frame.
      
      And second, is potentially the socket used to control a tunneling
      socket, such as one the encapsulates using UDP.
      
      We do not want to disassociate skb->sk when encapsulating in order
      to fix this, because that would break socket memory accounting.
      
      The most extreme case where this can cause huge problems is an
      AF_PACKET socket transmitting over a vxlan device.  We hit code
      paths doing checks that assume they are dealing with an ipv4
      socket, but are actually operating upon the AF_PACKET one.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7026b1dd
  8. 31 Mar, 2015 1 commit
  9. 12 Mar, 2015 1 commit
    • Eric W. Biederman's avatar
      net: Introduce possible_net_t · 0c5c9fb5
      Eric W. Biederman authored
      Having to say
      > #ifdef CONFIG_NET_NS
      > 	struct net *net;
      > #endif
      
      in structures is a little bit wordy and a little bit error prone.
      
      Instead it is possible to say:
      > typedef struct {
      > #ifdef CONFIG_NET_NS
      >       struct net *net;
      > #endif
      > } possible_net_t;
      
      And then in a header say:
      
      > 	possible_net_t net;
      
      Which is cleaner and easier to use and easier to test, as the
      possible_net_t is always there no matter what the compile options.
      
      Further this allows read_pnet and write_pnet to be functions in all
      cases which is better at catching typos.
      
      This change adds possible_net_t, updates the definitions of read_pnet
      and write_pnet, updates optional struct net * variables that
      write_pnet uses on to have the type possible_net_t, and finally fixes
      up the b0rked users of read_pnet and write_pnet.
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c5c9fb5
  10. 02 Sep, 2014 1 commit
    • 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
  11. 23 Apr, 2014 1 commit
  12. 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
  13. 15 Apr, 2014 1 commit
  14. 14 Mar, 2014 3 commits
  15. 07 Mar, 2014 1 commit
  16. 24 Feb, 2014 3 commits
  17. 20 Feb, 2014 1 commit
  18. 16 Feb, 2014 1 commit
    • Nicolas Dichtel's avatar
      ipsec: add support of limited SA dump · d3623099
      Nicolas Dichtel authored
      The goal of this patch is to allow userland to dump only a part of SA by
      specifying a filter during the dump.
      The kernel is in charge to filter SA, this avoids to generate useless netlink
      traffic (it save also some cpu cycles). This is particularly useful when there
      is a big number of SA set on the system.
      
      Note that I removed the union in struct xfrm_state_walk to fix a problem on arm.
      struct netlink_callback->args is defined as a array of 6 long and the first long
      is used in xfrm code to flag the cb as initialized. Hence, we must have:
      sizeof(struct xfrm_state_walk) <= sizeof(long) * 5.
      With the union, it was false on arm (sizeof(struct xfrm_state_walk) was
      sizeof(long) * 7), due to the padding.
      In fact, whatever the arch is, this union seems useless, there will be always
      padding after it. Removing it will not increase the size of this struct (and
      reduce it on arm).
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      d3623099
  19. 12 Feb, 2014 1 commit
  20. 13 Jan, 2014 1 commit
  21. 02 Jan, 2014 1 commit
  22. 16 Dec, 2013 1 commit
  23. 05 Dec, 2013 2 commits
    • Fan Du's avatar
      xfrm: Namespacify xfrm state/policy locks · 283bc9f3
      Fan Du authored
      By semantics, xfrm layer is fully name space aware,
      so will the locks, e.g. xfrm_state/pocliy_lock.
      Ensure exclusive access into state/policy link list
      for different name space with one global lock is not
      right in terms of semantics aspect at first place,
      as they are indeed mutually independent with each
      other, but also more seriously causes scalability
      problem.
      
      One practical scenario is on a Open Network Stack,
      more than hundreds of lxc tenants acts as routers
      within one host, a global xfrm_state/policy_lock
      becomes the bottleneck. But onces those locks are
      decoupled in a per-namespace fashion, locks contend
      is just with in specific name space scope, without
      causing additional SPD/SAD access delay for other
      name space.
      
      Also this patch improve scalability while as without
      changing original xfrm behavior.
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      283bc9f3
    • Fan Du's avatar
      xfrm: Using the right namespace to migrate key info · 8d549c4f
      Fan Du authored
      because the home agent could surely be run on a different
      net namespace other than init_net. The original behavior
      could lead into inconsistent of key info.
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      8d549c4f
  24. 09 Oct, 2013 1 commit
  25. 23 Sep, 2013 1 commit
  26. 28 Aug, 2013 1 commit
    • Fan Du's avatar
      {ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode callback · aba82695
      Fan Du authored
      Some thoughts on IPv4 VTI implementation:
      
      The connection between VTI receiving part and xfrm tunnel mode input process
      is hardly a "xfrm_tunnel", xfrm_tunnel is used in places where, e.g ipip/sit
      and xfrm4_tunnel, acts like a true "tunnel" device.
      
      In addition, IMHO, VTI doesn't need vti_err to do something meaningful, as all
      VTI needs is just a notifier to be called whenever xfrm_input ingress a packet
      to update statistics.
      
      A IPsec protected packet is first handled by protocol handlers, e.g AH/ESP,
      to check packet authentication or encryption rightness. PMTU update is taken
      care of in this stage by protocol error handler.
      
      Then the packet is rearranged properly depending on whether it's transport
      mode or tunnel mode packed by mode "input" handler. The VTI handler code
      takes effects in this stage in tunnel mode only. So it neither need propagate
      PMTU, as it has already been done if necessary, nor the VTI handler is
      qualified as a xfrm_tunnel.
      
      So this patch introduces xfrm_tunnel_notifier and meanwhile wipe out vti_err
      code.
      Signed-off-by: default avatarFan Du <fan.du@windriver.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: David S. Miller <davem@davemloft.net>
      Reviewed-by: default avatarSaurabh Mohan <saurabh.mohan@vyatta.com>
      Signed-off-by: default avatarSteffen Klassert <steffen.klassert@secunet.com>
      aba82695
  27. 26 Aug, 2013 1 commit
  28. 19 Aug, 2013 1 commit
  29. 14 Aug, 2013 2 commits
  30. 05 Aug, 2013 1 commit
  31. 31 May, 2013 1 commit