1. 17 3月, 2016 1 次提交
  2. 16 1月, 2016 1 次提交
  3. 12 12月, 2015 2 次提交
  4. 08 12月, 2015 1 次提交
  5. 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
  6. 23 10月, 2015 2 次提交
  7. 08 10月, 2015 5 次提交
  8. 29 9月, 2015 1 次提交
  9. 26 9月, 2015 1 次提交
  10. 18 9月, 2015 5 次提交
  11. 17 8月, 2015 1 次提交
  12. 11 8月, 2015 2 次提交
  13. 21 7月, 2015 1 次提交
  14. 04 6月, 2015 1 次提交
  15. 28 5月, 2015 3 次提交
  16. 21 5月, 2015 1 次提交
  17. 18 5月, 2015 1 次提交
  18. 13 5月, 2015 1 次提交
  19. 05 5月, 2015 2 次提交
  20. 29 4月, 2015 1 次提交
  21. 24 4月, 2015 1 次提交
  22. 23 4月, 2015 3 次提交
  23. 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
  24. 07 4月, 2015 1 次提交
    • A
      xfrm: fix xfrm_input/xfrm_tunnel_check oops · 68c11e98
      Alexey Dobriyan 提交于
      https://bugzilla.kernel.org/show_bug.cgi?id=95211
      
      Commit 70be6c91
      ("xfrm: Add xfrm_tunnel_skb_cb to the skb common buffer") added check
      which dereferences ->outer_mode too early but larval SAs don't have
      this pointer set (yet). So check for tunnel stuff later.
      
      Mike Noordermeer reported this bug and patiently applied all the debugging.
      
      Technically this is remote-oops-in-interrupt-context type of thing.
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000034
      IP: [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      	...
      [<ffffffff81500fc6>] ? xfrm4_esp_rcv+0x36/0x70
      [<ffffffff814acc9a>] ? ip_local_deliver_finish+0x9a/0x200
      [<ffffffff81471b83>] ? __netif_receive_skb_core+0x6f3/0x8f0
      	...
      
      RIP  [<ffffffff8150dca2>] xfrm_input+0x3c2/0x5a0
      Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      68c11e98