From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> To: paulmck <paulmck@kernel.org>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel <linux-kernel@vger.kernel.org>, lttng-dev <lttng-dev@lists.lttng.org> Subject: liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ? Date: Fri, 16 Apr 2021 10:52:16 -0400 (EDT) [thread overview] Message-ID: <1680415903.81652.1618584736742.JavaMail.zimbra@efficios.com> (raw) Hi Paul, Will, Peter, I noticed in this discussion https://lkml.org/lkml/2021/4/16/118 that LTO is able to break rcu_dereference. This seems to be taken care of by arch/arm64/include/asm/rwonce.h on arm64 in the Linux kernel tree. In the liburcu user-space library, we have this comment near rcu_dereference() in include/urcu/static/pointer.h: * The compiler memory barrier in CMM_LOAD_SHARED() ensures that value-speculative * optimizations (e.g. VSS: Value Speculation Scheduling) does not perform the * data read before the pointer read by speculating the value of the pointer. * Correct ordering is ensured because the pointer is read as a volatile access. * This acts as a global side-effect operation, which forbids reordering of * dependent memory operations. Note that such concern about dependency-breaking * optimizations will eventually be taken care of by the "memory_order_consume" * addition to forthcoming C++ standard. (note: CMM_LOAD_SHARED() is the equivalent of READ_ONCE(), but was introduced in liburcu as a public API before READ_ONCE() existed in the Linux kernel) Peter tells me the "memory_order_consume" is not something which can be used today. Any information on its status at C/C++ standard levels and implementation-wise ? Pragmatically speaking, what should we change in liburcu to ensure we don't generate broken code when LTO is enabled ? I suspect there are a few options here: 1) Fail to build if LTO is enabled, 2) Generate slower code for rcu_dereference, either on all architectures or only on weakly-ordered architectures, 3) Generate different code depending on whether LTO is enabled or not. AFAIU this would only work if every compile unit is aware that it will end up being optimized with LTO. Not sure how this could be done in the context of user-space. 4) [ Insert better idea here. ] Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
WARNING: multiple messages have this Message-ID (diff)
From: Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org> To: paulmck <paulmck@kernel.org>, Will Deacon <will@kernel.org>, Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel <linux-kernel@vger.kernel.org>, lttng-dev <lttng-dev@lists.lttng.org> Subject: [lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ? Date: Fri, 16 Apr 2021 10:52:16 -0400 (EDT) [thread overview] Message-ID: <1680415903.81652.1618584736742.JavaMail.zimbra@efficios.com> (raw) Hi Paul, Will, Peter, I noticed in this discussion https://lkml.org/lkml/2021/4/16/118 that LTO is able to break rcu_dereference. This seems to be taken care of by arch/arm64/include/asm/rwonce.h on arm64 in the Linux kernel tree. In the liburcu user-space library, we have this comment near rcu_dereference() in include/urcu/static/pointer.h: * The compiler memory barrier in CMM_LOAD_SHARED() ensures that value-speculative * optimizations (e.g. VSS: Value Speculation Scheduling) does not perform the * data read before the pointer read by speculating the value of the pointer. * Correct ordering is ensured because the pointer is read as a volatile access. * This acts as a global side-effect operation, which forbids reordering of * dependent memory operations. Note that such concern about dependency-breaking * optimizations will eventually be taken care of by the "memory_order_consume" * addition to forthcoming C++ standard. (note: CMM_LOAD_SHARED() is the equivalent of READ_ONCE(), but was introduced in liburcu as a public API before READ_ONCE() existed in the Linux kernel) Peter tells me the "memory_order_consume" is not something which can be used today. Any information on its status at C/C++ standard levels and implementation-wise ? Pragmatically speaking, what should we change in liburcu to ensure we don't generate broken code when LTO is enabled ? I suspect there are a few options here: 1) Fail to build if LTO is enabled, 2) Generate slower code for rcu_dereference, either on all architectures or only on weakly-ordered architectures, 3) Generate different code depending on whether LTO is enabled or not. AFAIU this would only work if every compile unit is aware that it will end up being optimized with LTO. Not sure how this could be done in the context of user-space. 4) [ Insert better idea here. ] Thoughts ? 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
next reply other threads:[~2021-04-16 14:52 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-16 14:52 Mathieu Desnoyers [this message] 2021-04-16 14:52 ` [lttng-dev] liburcu: LTO breaking rcu_dereference on arm64 and possibly other architectures ? 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
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=1680415903.81652.1618584736742.JavaMail.zimbra@efficios.com \ --to=mathieu.desnoyers@efficios.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lttng-dev@lists.lttng.org \ --cc=paulmck@kernel.org \ --cc=peterz@infradead.org \ --cc=will@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: linkBe 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.