Re: [Regression] stress-ng udp-flood causes kernel panic on Ampere Altra

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Jul 06, 2022 at 01:22:50PM +0100, Will Deacon wrote:

> > @@ -300,6 +300,9 @@ static inline bool nf_ct_is_expired(const struct nf_conn *ct)
> >  /* use after obtaining a reference count */
> >  static inline bool nf_ct_should_gc(const struct nf_conn *ct)
> >  {
> > +	/* ->status and ->timeout loads must happen after refcount increase */
> > +	smp_rmb();
> 
> Sorry I didn't suggest this earlier, but if all of these smp_rmb()s are
> for upgrading the ordering from refcount_inc_not_zero() then you should
> use smp_acquire__after_ctrl_dep() instead. It's the same under the hood,
> but it illustrates what's going on a bit better.

But in that case if had better also be near an actual condition,
otherwise things become too murky for words :/

That is, why is this sprinkled all over instead of right after
an successfull refcount_inc_not_zero() ?

Code like:

	if (!refcount_inc_not_zero())
		return;

	smp_acquire__after_ctrl_dep();

is fairly self-evident, whereas encountering an
smp_acquire__after_ctrl_dep() in a different function, completely
unrelated to any condition is quite crazy.

> > @@ -1775,6 +1784,16 @@ init_conntrack(struct net *net, struct nf_conn *tmpl,
> >  	if (!exp)
> >  		__nf_ct_try_assign_helper(ct, tmpl, GFP_ATOMIC);
> >  
> > +	/* Other CPU might have obtained a pointer to this object before it was
> > +	 * released.  Because refcount is 0, refcount_inc_not_zero() will fail.
> > +	 *
> > +	 * After refcount_set(1) it will succeed; ensure that zeroing of
> > +	 * ct->status and the correct ct->net pointer are visible; else other
> > +	 * core might observe CONFIRMED bit which means the entry is valid and
> > +	 * in the hash table, but its not (anymore).
> > +	 */
> > +	smp_wmb();
> > +
> >  	/* Now it is going to be associated with an sk_buff, set refcount to 1. */
> >  	refcount_set(&ct->ct_general.use, 1);
> 
> Ideally that refcount_set() would be a release, but this is definitely
> (ab)using refcount_t in way that isn't anticipated by the API! It looks
> like a similar pattern exists in net/core/sock.c as well, so I wonder if
> it's worth extending the API.
> 
> Peter, what do you think?

Bah; you have reminded me that I have a fairly sizable amount of
refcount patches from when Linus complained about it last that don't
seem to have gone anywhere :/

Anyway, I suppose we could do a refcount_set_release(), but it had
better get a fairly big comment on how you're on your own if you use it.