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

[Konstantin Ananyev]

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

Once again: pls point which exactly line(s) of code (and why) you 
believe contains undefined behavior.

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