[bug report] possible u64_stats_sync abuse

From: Yangfl <mmyangfl@gmail.com>
Date: 2026-01-08 01:21:25

Hi,

I've noticed many drivers use u64_stats_sync in a (possibly)
undesirable way, where the writers/readers use plain u64 operations
instead of opaque u64_stats_t. For example (not a complete list for
simplicity):

- drivers/net/ifb.c:164 : direct u64 read

do {
        start = u64_stats_fetch_begin(&txp->rx_stats.sync);
        packets = txp->rx_stats.packets;
        bytes = txp->rx_stats.bytes;
} while (u64_stats_fetch_retry(&txp->rx_stats.sync, start));

- drivers/net/macsec.c:2888 : memcpy (alignment boundary violation)

do {
        start = u64_stats_fetch_begin(&stats->syncp);
        memcpy(&tmp, &stats->stats, sizeof(tmp));
} while (u64_stats_fetch_retry(&stats->syncp, start));

- drivers/net/veth.c:234 : operations not revoked?

do {
        start = u64_stats_fetch_begin(&rq_stats->syncp);
        for (j = 0; j < VETH_TQ_STATS_LEN; j++) {
                offset = veth_tq_stats_desc[j].offset;
                data[tx_idx + j] += *(u64 *)(base + offset);
        }
} while (u64_stats_fetch_retry(&rq_stats->syncp, start));

While they may accidentally work on 32-bit architectures since
u64_stats_sync falls back to seqlock, it becomes no-op on 64-bit
architectures and compilers may send non atomic operations, although
the case is rare and one can hardly tell whether there are
inconsistencies in the statistics snapshot.

Should they be treated as bugs and fixed?

Regards
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help