linux-kernel - Re: [PATCH net-next 3/3] net: dsa: yt921x: Use 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: <20260205073913.1859434a@kernel.org>
Date: Thu, 5 Feb 2026 07:39:13 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: David Yang <mmyangfl@...il.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>, Vladimir Oltean
 <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] net: dsa: yt921x: Use u64_stats_t for MIB
 stats

On Thu, 5 Feb 2026 13:32:29 +0800 David Yang wrote:
> On Thu, Feb 5, 2026 at 1:12 PM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Wed,  4 Feb 2026 01:12:43 +0800 David Yang wrote:  
> > > 64-bit variables might not be atomic on 32-bit architectures, thus
> > > cannot be unconditionally made lock-free. Use u64_stats_t so it would
> > > still be lock-free on 64-bit architectures.  
> >
> > IDK why we need to worry about lock free reading of those 64b values...
> >  
> > > @@ -771,22 +785,27 @@ yt921x_dsa_get_ethtool_stats(struct dsa_switch *ds, int port, uint64_t *data)
> > >       struct yt921x_priv *priv = to_yt921x_priv(ds);
> > >       struct yt921x_port *pp = &priv->ports[port];
> > >       struct yt921x_mib *mib = &pp->mib;
> > > +     unsigned int start;
> > >       size_t j;
> > >
> > >       mutex_lock(&priv->reg_lock);
> > >       yt921x_read_mib(priv, port);
> > >       mutex_unlock(&priv->reg_lock);  
> >
> > ..when in all(?) the readers converted by this patch we take the mutex
> > to refresh the stats anyway. And presumably do expensive IO/reg reads
> > under that mutex. So just extend the mutex over the read section and
> > save us the retry logic, please, it will make no difference to perf.  
> 
> .get_stats64() is atomic, that's why everyone (mostly) is using
> u64_stats_t for DSA stats.

I understand, but only ndo_get_stats64() is, all the other cases like
ethtool stats can keep holding the lock and use u64 / u64_stats_read()
without a retry.

I had this argument with people before, I don't get why people try to
microoptimize device stats so much. The u64_stats* infra is really meant
for per-CPU/per-queue software stats which must have low overhead.