* Re: [PATCH] Wireguard: Fix data-race in rx/tx counter
[not found] ` <aa423184-7465-4bc9-aff4-d3d671beb3c6@lunn.ch>
@ 2026-06-29 2:34 ` Theodore Tso
0 siblings, 0 replies; only message in thread
From: Theodore Tso @ 2026-06-29 2:34 UTC (permalink / raw)
To: Andrew Lunn
Cc: Rafael Passos, Jason, andrew+netdev, davem, edumazet, kuba,
linux-kernel, netdev, pabeni, syzbot+9ca7674fa7521a3f1bc2,
syzkaller-bugs, wireguard
On Sun, Jun 28, 2026 at 11:02:05PM -0500, Andrew Lunn wrote:
> On Sun, Jun 28, 2026 at 05:38:23PM -0300, Rafael Passos wrote:
> > fixes data-race in {rx/tx}_bytes counter for wireguard connection.
> > these values were incremented inside a read_lock_bh block, but write
> > protections were missing. making them atomic was the simplest way out.
> > This was found by syzbot with kcsan.
>
> Atomics are expensive in general, especially on high CPU count
> systems.
>
> Statistic counters tend to be very asymmetric in usage. They are
> incremented frequently, maybe per packet, but reported very
> infrequently, maybe every minute when an SNMP agent reads them.
One of the reasons why kcsan and syzbot can be quite noisy is that a
human being needs to *think* and consider whether or not this is
actually important. (One of the reasons why I'm not all that worried
about our new AI overlords taking over the world. :-) Consider what
is the worst that might happen if the tx/rx_bytes counter might not be
completely accurate? Is it worth the performance penalty of using
atomics (or the memory overhead of per-CPU counters)?
- Ted
^ permalink raw reply [flat|nested] only message in thread