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

[Konstantin Ananyev]

>
> On 25/10/2026 07:44, Konstantin Ananyev wrote:
>>> 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.
>
> What you're saying is covered by the "neither happens before the 
> other" clause below. In our case there are no mutexes, rcu, etc. that 
> make the write happen before the read, or the read happen before the 
> right. So the paragraph applies.

Ok, can we probably return to my initial question:
in the code under discussion: where do you see a race condition,
and how exactly your changes fix it?

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