[PATCH v2 8/9] bpf: make callback handle atomic with relaxed access

[Konstantin Ananyev]

>
> 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.