All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>, David Yang <mmyangfl@gmail.com>,
	netdev@vger.kernel.org, Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next] net: alacritech: Use u64_stats_t with u64_stats_sync properly
Date: Mon, 26 Jan 2026 11:35:23 +0000	[thread overview]
Message-ID: <20260126113523.3663baee@pumpkin> (raw)
In-Reply-To: <CANn89iK9xfvQ275f+PPht8mM6K49mUq-T9D-4UUxUkTncM4tRw@mail.gmail.com>

On Mon, 26 Jan 2026 11:11:09 +0100
Eric Dumazet <edumazet@google.com> wrote:

> On Mon, Jan 26, 2026 at 12:23 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Fri, 23 Jan 2026 02:51:07 +0800 David Yang wrote:  
> > > On 64bit arches, struct u64_stats_sync is empty and provides no help
> > > against load/store tearing. Convert to u64_stats_t to ensure atomic
> > > operations.  
> >
> > Eric, could you comment if this matters? I expect David may send a
> > non-trivial number of these, I want to make sure we're making good
> > use of everyone's time here. 64b accesses are not torn on 64b arches,
> > and never used for control flow.  
> 
> I  added u64_stats_add()/u64_stats_inc() back in 2019, and never bothered
> sending dozens of patches.
> 
> Presumably compilers could be really dumb back then, I am not sure
> this is still the case today.
> 

gcc still generates 'crap code' for var_64 += var_32 on x86-32.
Basically it zero-extends then does a 64bit add rather than
using 'adc $0, %reg_hi', the extra register is likely to force
a spill to stack.
But that is 'fixed' by using add_u64_u32().

Oh and you really don't want to support adding a signed 32bit value
for one place that wants to do a subtract.

	David

  reply	other threads:[~2026-01-26 11:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-22 18:51 [PATCH net-next] net: alacritech: Use u64_stats_t with u64_stats_sync properly David Yang
2026-01-25 23:23 ` Jakub Kicinski
2026-01-26 10:11   ` Eric Dumazet
2026-01-26 11:35     ` David Laight [this message]
2026-01-27  3:00 ` patchwork-bot+netdevbpf

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=20260126113523.3663baee@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --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.