1. 27 3月, 2017 1 次提交
    • A
      xfrm: branchless addr4_match() on 64-bit · 6c786bcb
      Alexey Dobriyan 提交于
      Current addr4_match() code has special test for /0 prefixes because of
      standard required undefined behaviour. However, it is possible to omit
      it on 64-bit because shifting can be done within a 64-bit register and
      then truncated to the expected value (which is 0 mask).
      
      Implicit truncation by htonl() fits nicely into R32-within-R64 model
      on x86-64.
      
      Space savings: none (coincidence)
      Branch savings: 1
      
      Before:
      
      	movzx  eax,BYTE PTR [rdi+0x2a]		# ->prefixlen_d
      	test   al,al
      	jne    xfrm_selector_match + 0x23f
      		...
      	movzx  eax,BYTE PTR [rbx+0x2b]		# ->prefixlen_s
      	test   al,al
      	je     xfrm_selector_match + 0x1c7
      
      After (no branches):
      
      	mov    r8d,0x20
      	mov    rdx,0xffffffffffffffff
      	mov    esi,DWORD PTR [rsi+0x2c]
      	mov    ecx,r8d
      	sub    cl,BYTE PTR [rdi+0x2a]
      	xor    esi,DWORD PTR [rbx]
      	mov    rdi,rdx
      	xor    eax,eax
      	shl    rdi,cl
      	bswap  edi
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      6c786bcb
  2. 24 3月, 2017 2 次提交
  3. 15 2月, 2017 4 次提交
  4. 09 2月, 2017 4 次提交
  5. 17 1月, 2017 1 次提交
  6. 10 1月, 2017 2 次提交
  7. 21 9月, 2016 1 次提交
    • N
      vti6: fix input path · 63c43787
      Nicolas Dichtel 提交于
      Since commit 1625f452, vti6 is broken, all input packets are dropped
      (LINUX_MIB_XFRMINNOSTATES is incremented).
      
      XFRM_TUNNEL_SKB_CB(skb)->tunnel.ip6 is set by vti6_rcv() before calling
      xfrm6_rcv()/xfrm6_rcv_spi(), thus we cannot set to NULL that value in
      xfrm6_rcv_spi().
      
      A new function xfrm6_rcv_tnl() that enables to pass a value to
      xfrm6_rcv_spi() is added, so that xfrm6_rcv() is not touched (this function
      is used in several handlers).
      
      CC: Alexey Kodanev <alexey.kodanev@oracle.com>
      Fixes: 1625f452 ("net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key")
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      63c43787
  8. 10 8月, 2016 1 次提交
  9. 28 4月, 2016 2 次提交
  10. 12 12月, 2015 2 次提交
  11. 08 10月, 2015 1 次提交
  12. 18 9月, 2015 1 次提交
  13. 11 8月, 2015 1 次提交
  14. 28 5月, 2015 2 次提交
  15. 08 4月, 2015 1 次提交
    • D
      netfilter: Pass socket pointer down through okfn(). · 7026b1dd
      David Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      7026b1dd
  16. 01 4月, 2015 1 次提交
  17. 13 3月, 2015 1 次提交
    • E
      net: Introduce possible_net_t · 0c5c9fb5
      Eric W. Biederman 提交于
      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: N"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0c5c9fb5
  18. 02 9月, 2014 1 次提交
    • C
      xfrm: configure policy hash table thresholds by netlink · 880a6fab
      Christophe Gouault 提交于
      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: NChristophe Gouault <christophe.gouault@6wind.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      880a6fab
  19. 23 4月, 2014 1 次提交
  20. 22 4月, 2014 1 次提交
    • T
      xfrm: Remove useless secid field from xfrm_audit. · f1370cc4
      Tetsuo Handa 提交于
      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: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      f1370cc4
  21. 16 4月, 2014 1 次提交
  22. 14 3月, 2014 3 次提交
  23. 07 3月, 2014 1 次提交
  24. 25 2月, 2014 3 次提交
  25. 20 2月, 2014 1 次提交