All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>
To: Duncan Sands <baldrick@free.fr>
Cc: paulmck <paulmck@kernel.org>, lttng-dev <lttng-dev@lists.lttng.org>
Subject: Re: [lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ?
Date: Mon, 19 Apr 2021 11:54:37 -0400 (EDT)	[thread overview]
Message-ID: <2073969799.507.1618847677716.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <66ce5b4b-1992-26ab-9d76-e6a30ab2bbba@free.fr>

----- On Apr 19, 2021, at 11:41 AM, Duncan Sands baldrick@free.fr wrote:

> Hi Mathieu,
> 
> On 4/19/21 5:31 PM, Mathieu Desnoyers wrote:
>> ----- On Apr 19, 2021, at 5:41 AM, Duncan Sands baldrick@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.

Considering that rcu_dereference is public API, we would have to wait until we
do a major soname ABI bump _and_ an API break to do that, which I am very
reluctant to do, especially for the API break part.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

      reply	other threads:[~2021-04-19 15:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 14:52 liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ? Mathieu Desnoyers
2021-04-16 14:52 ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2021-04-16 15:17 ` Peter Zijlstra
2021-04-16 15:17   ` [lttng-dev] " Peter Zijlstra via lttng-dev
2021-04-16 16:01   ` Paul E. McKenney
2021-04-16 16:01     ` [lttng-dev] " Paul E. McKenney via lttng-dev
2021-04-16 18:40     ` Mathieu Desnoyers
2021-04-16 18:40       ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2021-04-16 19:02       ` Paul E. McKenney
2021-04-16 19:02         ` [lttng-dev] " Paul E. McKenney via lttng-dev
2021-04-16 19:30         ` Mathieu Desnoyers
2021-04-16 19:30           ` [lttng-dev] " Mathieu Desnoyers via lttng-dev
2021-04-16 20:01           ` Paul E. McKenney
2021-04-16 20:01             ` [lttng-dev] " Paul E. McKenney via lttng-dev
2021-04-16 15:22 ` Duncan Sands via lttng-dev
2021-04-16 20:39   ` Mathieu Desnoyers via lttng-dev
     [not found]     ` <7972b031-59b9-7fb5-6379-58bcec13a769@free.fr>
2021-04-19 15:31       ` Mathieu Desnoyers via lttng-dev
2021-04-19 15:41         ` Duncan Sands via lttng-dev
2021-04-19 15:54           ` Mathieu Desnoyers via lttng-dev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2073969799.507.1618847677716.JavaMail.zimbra@efficios.com \
    --to=lttng-dev@lists.lttng.org \
    --cc=baldrick@free.fr \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.