netdev - 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: <CAAXyoMMJsWK8F5neewwZHtEHe0-iT1rbfPekSDXm7HJvG2bOpQ@mail.gmail.com>
Date: Thu, 22 Jan 2026 23:13:43 +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 7:20 PM Sabrina Dubroca <sd@...asysnail.net> wrote:
>
> 2026-01-22, 02:22:49 +0800, Yangfl wrote:
> > 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.
>
> It would be a bit more consistent. Just within this function you have
> 2 lines using u64_stats_t and the 3rd uses local64_t. And reusing
> types/helpers within a similar context doesn't seem overkill.
>
>
> [...]
> > > 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.
>
> I'm not sure why they would. I think the main point of using memcpy is
> "I don't want to copy each counter by name one by one", and possibly
> "I don't want to have to patch this code as well if we add a new
> counter". If you already have a batch copy for a bunch of counters,
> it's usually easier to add others in a contiguous block.
>

While I agree with your statement, I don't think it's a good idea to
push the retry loop into the helper. u64_stats_copy(syncp, dst, src,
len) would be a strange API, while no others accept syncp argument.
Also, it would give a false appearance to those who read the driver
code, since it does not involve fetch_begin()/fetch_retry()
explicitly.

In my opinion, it would be better to introduce a for-like macro
#define with_u64_stats_fetch(syncp), eliminating two function calls as
well as one variable declaration altogether.