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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 Jul 2022 16:00:58 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Will Deacon <will@...nel.org>
Cc:     Florian Westphal <fw@...len.de>,
        Kajetan Puchalski <kajetan.puchalski@....com>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...filter.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Mel Gorman <mgorman@...e.de>,
        lukasz.luba@....com, dietmar.eggemann@....com,
        mark.rutland@....com, broonie@...nel.org,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org, stable@...r.kernel.org,
        regressions@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [Regression] stress-ng udp-flood causes kernel panic on Ampere
 Altra

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.