[lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ?

Duncan Sands baldrick at free.fr
Mon Apr 19 11:41:16 EDT 2021

Hi Mathieu,

On 4/19/21 5:31 PM, Mathieu Desnoyers wrote:
> ----- On Apr 19, 2021, at 5:41 AM, Duncan Sands baldrick at free.fr wrote:
>>> Quick question: should we use __atomic_load() or atomic_load_explicit() (C) and
>>> (std::atomic<__typeof__(x)>)(x)).load() (C++) ?
>> If both are available, is there any advantage to using the C++ version when
>> compiling C++?  As opposed to using the C11 one for both C and C++?
> I recently noticed that using C11/C++11 atomic load explicit is not a good
> fit for rcu_dereference, because we want the type to be a pointer, not an
> _Atomic type. gcc appears to accept a looser typing, but clang has issues
> trying to build that code.

in the long run maybe the original variables should be declared with the 
appropriate atomic type from the get-go.

> So I plan to use __atomic(p, v, __ATOMIC_CONSUME) instead in both C and C++.
> Also, I'll drop the cmm_smp_read_barrier_depends() when using __ATOMIC_CONSUME,
> because AFAIU their memory ordering semantics are redundant for rcu_dereference.

Yeah, keeping the barrier makes no sense in that case.

> Here is the resulting commit for review on gerrit:
> https://review.lttng.org/c/userspace-rcu/+/5455 Fix: use __atomic_load() rather than atomic load explicit [NEW]

Looks good to me (I didn't test it though).

Ciao, Duncan.

More information about the lttng-dev mailing list