From: David Laight <david.laight.linux@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: David Yang <mmyangfl@gmail.com>,
netdev@vger.kernel.org, Aaron Conole <aconole@redhat.com>,
Eelco Chaudron <echaudro@redhat.com>,
Ilya Maximets <i.maximets@ovn.org>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
dev@openvswitch.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2 4/7] net: openvswitch: fix load tearing with u64_stats
Date: Mon, 26 Jan 2026 19:18:55 +0000 [thread overview]
Message-ID: <20260126191855.04018872@pumpkin> (raw)
In-Reply-To: <CANn89iJrDgD4J=mgWRcQMW70621OUV37hucj76ugZUXBLdy_VQ@mail.gmail.com>
On Mon, 26 Jan 2026 19:35:38 +0100
Eric Dumazet <edumazet@google.com> wrote:
> On Mon, Jan 26, 2026 at 7:29 PM David Laight
> <david.laight.linux@gmail.com> wrote:
> >
> > On Sat, 24 Jan 2026 00:21:36 +0800
> > David Yang <mmyangfl@gmail.com> wrote:
> >
> > > On 64bit arches, struct u64_stats_sync is empty and provides no help
> > > against load/store tearing. struct copying should not be considered
> > > tear-free. Use u64_stats_reads() instead.
> >
> > Except that the compiler doesn't ever generate 'tearing accesses' for
> > aligned 64bit accesses on any 64bit architecture.
> > Similarly memcpy() won't generate problematic accesses.
> >
> > The problem is purely theoretical - the C language lets the compiler
> > split accesses, but it doesn't.
>
> Yeah, although we still have races that KCSAN can detect.
>
> data_race() or READ_ONCE() would be necessary to avoid noisy KCSAN reports.
>
> While many KCSAN reports are boring, some of them point to real bugs.
>
Could something be put in u64_stats_fetch_begin() to stop KCSAN bleating?
With the way READ_ONCE and WRITE_ONCE now get enforced I do wonder if
some data shouldn't just be marked 'volatile'?
That would give 'non-tearing' accesses, but without the inter-cpu
ordering that (I think) READ/WRITE_ONCE also give.
For stats counters that is enough.
David
next prev parent reply other threads:[~2026-01-26 19:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 16:21 [PATCH net-next v2 0/7] u64_stats: Introduce u64_stats_reads() David Yang
2026-01-23 16:21 ` [PATCH net-next v2 1/7] " David Yang
2026-01-23 16:21 ` [PATCH net-next v2 2/7] u64_stats: Doc incorrect usage with plain variables David Yang
2026-01-23 16:21 ` [PATCH net-next v2 3/7] net: bridge: mcast: fix memcpy with u64_stats David Yang
2026-01-23 16:21 ` [PATCH net-next v2 4/7] net: openvswitch: fix load tearing " David Yang
2026-01-24 0:49 ` kernel test robot
2026-01-26 12:25 ` Ilya Maximets
2026-01-26 18:29 ` David Laight
2026-01-26 18:35 ` Eric Dumazet
2026-01-26 19:18 ` David Laight [this message]
2026-01-23 16:21 ` [PATCH net-next v2 5/7] macsec: fix memcpy " David Yang
2026-01-23 16:21 ` [PATCH net-next v2 6/7] mpls: Fix load tearing " David Yang
2026-01-23 16:21 ` [PATCH net-next v2 7/7] vxlan: vnifilter: fix memcpy " David Yang
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=20260126191855.04018872@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=aconole@redhat.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mmyangfl@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.