From: David Laight <david.laight.linux@gmail.com>
To: Florian Westphal <fw@strlen.de>
Cc: Anders Grahn <anders.grahn@gmail.com>,
Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Phil Sutter <phil@nwl.cc>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Anders Grahn <anders.grahn@westermo.com>,
linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, netdev@vger.kernel.org
Subject: Re: [PATCH] netfilter: nft_counter: Fix reset of counters on 32bit archs
Date: Mon, 15 Dec 2025 13:53:01 +0000 [thread overview]
Message-ID: <20251215135301.75986b89@pumpkin> (raw)
In-Reply-To: <aUAAuyGGhDjyfNoM@strlen.de>
On Mon, 15 Dec 2025 13:36:11 +0100
Florian Westphal <fw@strlen.de> wrote:
> Anders Grahn <anders.grahn@gmail.com> wrote:
> > nft_counter_reset() calls u64_stats_add() with a negative value to reset
> > the counter. This will work on 64bit archs, hence the negative value
> > added will wrap as a 64bit value which then can wrap the stat counter as
> > well.
> >
> > On 32bit archs, the added negative value will wrap as a 32bit value and
> > _not_ wrapping the stat counter properly. In most cases, this would just
> > lead to a very large 32bit value being added to the stat counter.
> >
> > Fix by introducing u64_stats_sub().
> >
> > Fixes: 4a1d3acd6ea8 ("netfilter: nft_counter: Use u64_stats_t for statistic")
> > Signed-off-by: Anders Grahn <anders.grahn@westermo.com>
> > ---
> > include/linux/u64_stats_sync.h | 10 ++++++++++
> > net/netfilter/nft_counter.c | 4 ++--
> > 2 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
> > index 457879938fc1..9942d29b17e5 100644
> > --- a/include/linux/u64_stats_sync.h
> > +++ b/include/linux/u64_stats_sync.h
> > @@ -89,6 +89,11 @@ static inline void u64_stats_add(u64_stats_t *p, unsigned long val)
> > local64_add(val, &p->v);
> > }
> >
> > +static inline void u64_stats_sub(u64_stats_t *p, unsigned long val)
> > +{
> > + local64_sub(val, &p->v);
> > +}
>
> That still truncates val on 32bit. Maybe use "s64 val"?
>
It probably depends on the type of total->bytes and total->packets.
The 'bytes' value will wrap 32bits quickly, so may need to be 64bit anyway.
And if (elsewhere) there are this_cpu->bytes += val; total->bytes += val;
pairs you can't 'undo' the adds once total->bytes has wrapped.
So should any of these types be 'long' at all?
I sometimes think that 'long' should be pretty much never used in the
kernel because of the 32bit/64bit portability issues.
But that should have been sorted over 20 years ago.
Maybe M$ had it right keeping long as 32bits :-)
David
next prev parent reply other threads:[~2025-12-15 13:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-15 12:12 [PATCH] netfilter: nft_counter: Fix reset of counters on 32bit archs Anders Grahn
2025-12-15 12:36 ` Florian Westphal
2025-12-15 13:53 ` David Laight [this message]
2025-12-15 14:01 ` Anders Grahn
2025-12-15 14:54 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251215135301.75986b89@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=anders.grahn@gmail.com \
--cc=anders.grahn@westermo.com \
--cc=bigeasy@linutronix.de \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.