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.
