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

[Marat Khalili]

On 25/10/2026 10:53, Konstantin Ananyev wrote:
>
>>
>> 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?
I see undefined behaviour according to the definition below. This 
definition depends on actions "at least one of which is not atomic", so 
making all the actions atomic removes one of the conditions for the 
undefined behaviour, making the behaviour defined.
>>>>     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.