Sorry, but I have absolutely no context here. We have a handy document describing the differences between atomic_t and refcount_t:
Documentation/core-api/refcount-vs-atomic.rst
What else do you need to know?
Hmm, and I see a tonne of *_inc_not_zero() conversions in 719774377622 ("netfilter: conntrack: convert to refcount_t api") which mean that you no longer have ordering to subsequent reads in the absence of an address dependency.
I think the patch above needs auditing with the relaxed behaviour in mind, but for the specific crash reported here possibly something like the diff below?
Will
--->8
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 082a2fd8d85b..5ad9fcc84269 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1394,6 +1394,7 @@ static unsigned int early_drop_list(struct net *net, * already fired or someone else deleted it. Just drop ref * and move to next entry. */
smp_rmb(); /* XXX: Why? */ if (net_eq(nf_ct_net(tmp), net) && nf_ct_is_confirmed(tmp) && nf_ct_delete(tmp, 0, 0))
With this patch applied the issue goes away as well. The test runs fine well beyond where it would crash previously so looks good, thanks!