kernel-packages team mailing list archive

[Dan Streetman <dan.streetman@xxxxxxxxxxxxx>]

the systemtap script below can be used to monitor the dst count for all
net namespaces.  When any of the counts goes significantly negative
(more than 32 * CPUS negative) it indicates this bug is reproduced -
meaning, the count from one net namespace was incorrectly shifted to
another net namespace, and once that happens enough times one (or more)
net namespaces have a count that goes negative (which is not possible).
Other net namespaces have counts that are much higher than they should
be.  Note this script is just for ipv4, but the bug exists for ipv6 also
(and the patch fixes ipv6 also).

#!/usr/bin/stap

global dst_count

probe kernel.function("xfrm_resolve_and_create_bundle") {
  if ($family == 2) {
    dst_count[&$pols[0]->xp_net] = $pols[0]->xp_net->xfrm->xfrm4_dst_ops->pcpuc_entries->count
  }
}

probe timer.sec(1) {
  foreach (c in dst_count) {
    printf("%ld ", dst_count[c])
  }
  print("\n")
}

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1486670

Title:
  using ipsec, many connections result in no buffer space error

Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Precise:
  Invalid
Status in linux source package in Trusty:
  Fix Committed
Status in linux source package in Vivid:
  Fix Committed
Status in linux source package in Wily:
  Fix Committed

Bug description:
  Reproduction info:

  set up two LXC containers (although this probably isn't specific to
  LXC containers), and inside each setup ipsec with something similar
  to:

  conn nodeN
  aggressive=yes 
  authby=secret 
  auto=start 
  closeaction=restart 
  dpdaction=restart 
  esp=aes256-aes256gmac-modp1024 
  ike=aes256-sha512-modp1024 
  keyexchange=ikev2 
  left=10.0.3.145 
  leftid=10.0.3.145 
  lifetime=12h 
  reauth=no 
  right=10.0.3.199 
  type=transport 

  
  then repeatedly open connections to the peer, e.g.:

  while true; do ping -c1 10.0.3.199 ; sleep 0.1 ; done

  eventually, the connections will fail with:

  connect: No buffer space available

  the reproduction can be sped up by reducing the xfrm4_gc_thresh, e.g.:

  echo 5 > /proc/sys/net/ipv4/xfrm4_gc_thresh

  
  Once the error occurs, no more connections can be made to the peer (all fail with no buffer space available), however after a long period (e.g. overnight) the buffers will be cleaned up and connections can be made again.

  this happens even on the latest net-next kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1486670/+subscriptions