[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iJrDgD4J=mgWRcQMW70621OUV37hucj76ugZUXBLdy_VQ@mail.gmail.com>
Date: Mon, 26 Jan 2026 19:35:38 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: David Laight <david.laight.linux@...il.com>
Cc: David Yang <mmyangfl@...il.com>, netdev@...r.kernel.org,
Aaron Conole <aconole@...hat.com>, Eelco Chaudron <echaudro@...hat.com>,
Ilya Maximets <i.maximets@....org>, "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
dev@...nvswitch.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next v2 4/7] net: openvswitch: fix load tearing with u64_stats
On Mon, Jan 26, 2026 at 7:29 PM David Laight
<david.laight.linux@...il.com> wrote:
>
> On Sat, 24 Jan 2026 00:21:36 +0800
> David Yang <mmyangfl@...il.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 LCSAN reports are boring, some of them point to real bugs.
Powered by blists - more mailing lists