summaryrefslogtreecommitdiff
path: root/include/uapi/linux/errqueue.h
diff options
context:
space:
mode:
authorRunyu Xiao <runyu.xiao@seu.edu.cn>2026-10-27 15:31:09 +0100
committerMarc Kleine-Budde <mkl@pengutronix.de>2026-11-03 19:54:29 +0100
commit12297f855bbd943847cb8893a3614caef5a9c2a8 (patch)
treefb158c1800ddfea95c36c51263b4b39d1f5f824d /include/uapi/linux/errqueue.h
parent43c973a0887d3d7b2ee0a446603c97bf0f38c58e (diff)
can: proc: reset pkg_stats atomics individually
Commit 80b5f90158d1 ("can: statistics: use atomic access in hot path") converted several members of struct can_pkg_stats to atomic_long_t and updated the hot TX/RX and procfs read paths to use atomic_long_*() helpers. However, can_init_stats() still clears the whole struct with memset(). can_init_stats() is reached from can_stat_update() in timer context and also from the procfs reset path. Those paths can run while the TX/RX hot paths are concurrently updating rx_frames, tx_frames, matches and their *_delta counters. Hitting the whole-struct memset() in that window performs plain writes to fields that otherwise follow an atomic_long_t access contract, which can lose or mix live statistics updates. This issue was found by source-level API-misuse analysis looking for whole-object resets left behind after atomic_long_t conversions, then manually audited on Linux v6.18.21. Replace the whole-struct memset() with a helper that resets the atomic_long_t counters via atomic_long_set() and clears the derived scalar statistics explicitly. This preserves the existing reset semantics for scalar fields while restoring atomic access discipline for the live counters. Build-tested by compiling net/can/proc.o on x86_64 netdev/main. Runtime-tested with a QEMU + vcan setup on Linux v6.18.21 by driving concurrent traffic and reset_stats reads, which reproduced inconsistent exported statistics before the fix. [Hartkopp] can_stat_update() also read the *_delta counters at the beginning and cleared them with atomic_long_set() at the end. Increments from the hot path in between were lost for both the current and the next interval. Use atomic_long_xchg() to fetch and clear the *_delta counters in one atomic step instead. On x86_64 atomic_long_set() is a plain store like memset(), so the memset() is an actual problem only on architectures with lock-based atomics (e.g. parisc). The inconsistencies seen on x86_64 come from the *_delta handling and from the stale snapshots, which are fixed in "can: proc: skip stats calculation after reset in can_stat_update()". As before, the counters are reset one at a time and the derived scalar statistics use plain stores. Fixes: 80b5f90158d1 ("can: statistics: use atomic access in hot path") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Acked-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20261027-can-rx-lock-v12-5-eb5afc2d8b9b@hartkopp.net Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Diffstat (limited to 'include/uapi/linux/errqueue.h')
0 files changed, 0 insertions, 0 deletions