On 19/10/2026 22:27, Konstantin Ananyev wrote:
The callback handle member cb of struct bpf_eth_cbi is concurrently
cleared by the control plane on unload and read by the datapath to
decide whether to execute the BPF filter program. Without atomic
typing,
this concurrent access constitutes a data race in the C11 memory model,
Hmm... why is that?
So far, I don't see any.
Can you probably point where you believe is a data-race, and how
using atomic
load/store can prevent it.
It follows from the standard (5.1.2.4 Multi-threaded executions and
data races):
Two expression evaluations conflict if one of them modifies a
memory location and the
other one reads or modifies the same memory location. [...]
Well, that's why people invented different synchronization methods:
mutexes, rcu, etc. :)
If you want to protect your data against data-races it soesn't mean yopu
have to make
all your data reads/writes atomic - you need to select a proper sync
mechanism around
it, so you can keep using normal reads/writes for the data itself.
BTW, just blindly making data reads/writes atomic doesn't guarantee that
there will be
no race conditions.
The execution of a program contains a data race if it contains two
conflicting actions in
different threads, at least one of which is not atomic, and
neither happens before the
other. Any such data race results in undefined behavior.
