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).
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" ) { count[& $pols[0] ->xp_net] = $pols[0] ->xp_net- >xfrm-> xfrm4_dst_ ops->pcpuc_ entries- >count
if ($family == 2) {
dst_
}
}
probe timer.sec(1) {
foreach (c in dst_count) {
printf("%ld ", dst_count[c])
}
print("\n")
}