linux-kernel - Re: [PATCH net-next 1/4] u64_stats: Introduce u64_stats

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] [day] [month] [year] [list]

Message-ID: <CAAXyoMMAMAbEu=-wTf3MGMiZr2Uq7pqJXC+_zrtxKrsjyYi+AQ@mail.gmail.com>
Date: Thu, 22 Jan 2026 02:22:49 +0800
From: Yangfl <mmyangfl@...il.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Nikolay Aleksandrov <razor@...ckwall.org>, Ido Schimmel <idosch@...dia.com>, Simon Horman <horms@...nel.org>, 
	Mark Bloch <mbloch@...dia.com>, Petr Machata <petrm@...dia.com>, 
	Stanislav Fomichev <sdf@...ichev.me>, Carolina Jubran <cjubran@...dia.com>, Breno Leitao <leitao@...ian.org>, 
	Shigeru Yoshida <syoshida@...hat.com>, linux-kernel@...r.kernel.org, bridge@...ts.linux.dev
Subject: Re: [PATCH net-next 1/4] u64_stats: Introduce u64_stats_copy()

On Thu, Jan 22, 2026 at 1:23 AM Sabrina Dubroca <sd@...asysnail.net> wrote:
>
> 2026-01-20, 17:21:29 +0800, David Yang wrote:
> > The following (anti-)pattern was observed in the code tree:
> >
> >         do {
> >                 start = u64_stats_fetch_begin(&pstats->syncp);
> >                 memcpy(&temp, &pstats->stats, sizeof(temp));
> >         } while (u64_stats_fetch_retry(&pstats->syncp, start));
> >
> > On 64bit arches, struct u64_stats_sync is empty and provides no help
> > against load/store tearing, especially for memcpy(), for which arches may
> > provide their highly-optimized implements.
> >
> > In theory the affected code should convert to u64_stats_t, or use
> > READ_ONCE()/WRITE_ONCE() properly.
> >
> > However since there are needs to copy chunks of statistics, instead of
> > writing loops at random places, we provide a safe memcpy() variant for
> > u64_stats.
> >
> > Signed-off-by: David Yang <mmyangfl@...il.com>
> > ---
> >  include/linux/u64_stats_sync.h | 15 +++++++++++++++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/include/linux/u64_stats_sync.h b/include/linux/u64_stats_sync.h
> > index 457879938fc1..849ff6e159c6 100644
> > --- a/include/linux/u64_stats_sync.h
> > +++ b/include/linux/u64_stats_sync.h
> > @@ -79,6 +79,14 @@ static inline u64 u64_stats_read(const u64_stats_t *p)
> >       return local64_read(&p->v);
> >  }
> >
> > +static inline void *u64_stats_copy(void *dst, const void *src, size_t len)
> > +{
> > +     BUILD_BUG_ON(len % sizeof(u64_stats_t));
> > +     for (size_t i = 0; i < len / sizeof(u64_stats_t); i++)
> > +             ((u64 *)dst)[i] = local64_read(&((local64_t *)src)[i]);
>
> Maybe u64_stats_read/u64_stats_t instead of local64_read/local64_t?
>

I think casting to u64_stats_t is a bit overkill here since we accept
const void * and we are the actual implementation.

Again, they should convert to u64_stats_t, and this solution already
implies that u64_stats_t is binary compatible with u64. I've already
sent several patches related to that, but that's another issue.

> > +     return dst;
> > +}
>
> Since this new helper is always used within a
> u64_stats_fetch_begin/u64_stats_fetch_retry loop, maybe it would be
> nicer to push the retry loop into the helper as well?  Not a strong
> opinion. It would be a bit "simpler" for the callers, but your current
> proposal has the advantage of looking like memcpy(), and of also
> looking (for the caller) like other retry loops fetching each counter
> explicitly.
>

The callers may want to copy other discontinuous data as well, albeit
no one did it then.

         do {
                 start = u64_stats_fetch_begin(&pstats->syncp);
                 memcpy(...);
                 u64_stats_read(...);
         } while (u64_stats_fetch_retry(&pstats->syncp, start));

It would be redundant to provide two variants of the function.
Moreover, callers can (and already) invent their own reader/writer
helpers, for example

         #define SLIC_GET_STATS_COUNTER(newst, st, counter) \
         { \
                  unsigned int start; \
                  do { \
                          start = u64_stats_fetch_begin(&(st)->syncp); \
                          newst = u64_stats_read(&(st)->counter); \
                  } while (u64_stats_fetch_retry(&(st)->syncp, start)); \
         }

> Either way, I think extending the "Usage" section of the big comment
> at the top of the file with this new helper would be nice.
>

I think callers should avoid memcpy() eventually, and they almost
certainly copied more data than what they need. However, I took a look
at some instances, and it would be non trivial to modify those
drivers.

> --
> Sabrina