From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Boqun Feng <boqun.feng@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>,
linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
linux-mm@kvack.org, lkmm@lists.linux.dev,
"Paul E. McKenney" <paulmck@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>,
rostedt <rostedt@goodmis.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Mark Rutland <mark.rutland@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Kent Overstreet <kent.overstreet@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
maged.michael@gmail.com,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>
Subject: Re: [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers
Date: Fri, 27 Sep 2024 10:43:59 -0400 [thread overview]
Message-ID: <08423acb-1f8e-407a-80fe-c424c6ee2861@efficios.com> (raw)
In-Reply-To: <8aceaf4f-5578-4fca-8be7-3448d7b89721@efficios.com>
On 2024-09-27 12:59, Mathieu Desnoyers wrote:
> On 2024-09-27 06:28, Boqun Feng wrote:
[...]
>> I replaced ADDRESS_EQ(a, b) with ADDRESS_EQ(b, a), and the compile
>> result shows it can prevent the issue:
>
> I see, yes. It prevents the issue by making the compiler create
> a copy of the value "modified" by the asm before doing the equality
> comparison.
>
> This means the compiler cannot derive the value for b from the first
> load when b is used after after the equality comparison.
>
> The only downside of OPTIMIZER_HIDE_VAR() is that it adds an extra
> "mov" instruction to move the content across registers. I don't think
> it matters performance wise though, so that solution is appealing
> because it is arch-agnostic.
>
> One small improvement over your proposed solution would be to apply
> OPTIMIZER_HIDE_VAR() on both inputs. Because this is not a volatile
> asm, it is simply optimized away if var1 or var2 is unused following
> the equality comparison. It is more convenient to prevent replacement
> of both addresses being compared by the other rather than providing
> the guarantee only on a single parameter:
Actually, your approach is better (only preserving the address
dependency on the first parameter), because it allows the second
parameter to be a constant.
Here is a diff. Please let me know if I need to improve anything wrt
comments or implementation:
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 2df665fa2964..52434eccd715 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -186,6 +186,32 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
__asm__ ("" : "=r" (var) : "0" (var))
#endif
+/*
+ * Compare an address with an expression while preserving the address
+ * dependencies for later use of the address. It should be used when
+ * comparing an address returned by rcu_dereference() with another
+ * address (either constant or in registers).
+ *
+ * This is needed to prevent the compiler SSA GVN optimization pass from
+ * replacing the register holding @addr by @expr (either a constant or a
+ * register) based on their equality, which does not preserve address
+ * dependencies and allows the following misordering speculations:
+ *
+ * - If @expr is a constant, the compiler can issue the loads which depend
+ * on @addr before the load of @addr.
+ * - If @expr is a register populated by a prior load, weakly-ordered
+ * CPUs can speculate loads which depend on @addr before the load of the
+ * address they depend on.
+ */
+#ifndef ADDRESS_EQ
+#define ADDRESS_EQ(addr, expr) \
+ ({ \
+ bool __res = (addr) == (expr); \
+ OPTIMIZER_HIDE_VAR(addr); \
+ __res; \
+ })
+#endif
+
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
/**
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
next prev parent reply other threads:[~2024-09-27 14:46 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-17 14:33 [RFC PATCH 0/4] Add hazard pointers to kernel Boqun Feng
2024-09-17 14:33 ` [RFC PATCH 1/4] hazptr: Add initial implementation of hazard pointers Boqun Feng
2024-09-18 8:27 ` Mathieu Desnoyers
2024-09-18 15:17 ` Alan Huang
2024-09-19 6:56 ` Boqun Feng
2024-09-19 18:07 ` Jonas Oberhauser
2024-09-19 0:12 ` Jann Horn
2024-09-19 20:30 ` Jonas Oberhauser
2024-09-20 7:43 ` Jonas Oberhauser
2024-09-19 6:39 ` Lai Jiangshan
2024-09-19 7:10 ` Boqun Feng
2024-09-19 12:33 ` Alan Huang
2024-09-19 13:57 ` Alan Huang
2024-09-19 18:58 ` Boqun Feng
2024-09-19 19:53 ` Alan Huang
2024-09-19 16:10 ` Alan Huang
2024-09-19 14:00 ` Jonas Oberhauser
2024-09-20 7:41 ` Jonas Oberhauser
2024-09-25 10:02 ` Boqun Feng
2024-09-25 10:11 ` Jonas Oberhauser
2024-09-25 10:45 ` Boqun Feng
2024-09-25 11:59 ` Mathieu Desnoyers
2024-09-25 12:16 ` Boqun Feng
2024-09-25 12:47 ` Mathieu Desnoyers
2024-09-25 13:10 ` Mathieu Desnoyers
2024-09-25 13:20 ` Mathieu Desnoyers
2024-09-26 6:16 ` Mathieu Desnoyers
2024-09-26 15:53 ` Jonas Oberhauser
2024-09-26 16:12 ` Linus Torvalds
2024-09-26 16:40 ` Jonas Oberhauser
2024-09-26 16:54 ` Linus Torvalds
2024-09-27 0:01 ` Boqun Feng
2024-09-27 1:30 ` Mathieu Desnoyers
2024-09-27 1:37 ` Boqun Feng
2024-09-27 4:28 ` Boqun Feng
2024-09-27 10:59 ` Mathieu Desnoyers
2024-09-27 14:43 ` Mathieu Desnoyers [this message]
2024-09-27 15:22 ` Mathieu Desnoyers
2024-09-27 16:06 ` Alan Huang
2024-09-27 16:44 ` Linus Torvalds
2024-09-27 17:15 ` Mathieu Desnoyers
2024-09-27 17:23 ` Linus Torvalds
2024-09-27 17:51 ` Mathieu Desnoyers
2024-09-27 18:13 ` Linus Torvalds
2024-09-27 19:12 ` Jonas Oberhauser
2024-09-27 19:28 ` Linus Torvalds
2024-09-27 20:24 ` Linus Torvalds
2024-09-27 20:02 ` Mathieu Desnoyers
2024-09-27 1:20 ` Mathieu Desnoyers
2024-09-27 4:38 ` Boqun Feng
2024-09-27 19:23 ` Jonas Oberhauser
2024-09-27 20:10 ` Mathieu Desnoyers
2024-09-27 22:18 ` Jonas Oberhauser
2024-09-28 22:10 ` Alan Huang
2024-09-28 23:12 ` Alan Huang
2024-09-25 12:19 ` Jonas Oberhauser
2024-09-17 14:34 ` [RFC PATCH 2/4] refscale: Add benchmarks for hazptr Boqun Feng
2024-09-17 14:34 ` [RFC PATCH 3/4] refscale: Add benchmarks for percpu_ref Boqun Feng
2024-09-17 14:34 ` [RFC PATCH 4/4] WIP: hazptr: Add hazptr test sample Boqun Feng
2024-09-17 19:51 ` kernel test robot
2024-09-18 7:18 ` [RFC PATCH 0/4] Add hazard pointers to kernel Linus Torvalds
2024-09-18 22:44 ` Neeraj Upadhyay
2024-09-19 6:46 ` Linus Torvalds
2024-09-20 5:00 ` Neeraj Upadhyay
2024-09-19 14:30 ` Mateusz Guzik
2024-09-19 14:14 ` Christoph Hellwig
2024-09-19 14:21 ` Linus Torvalds
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=08423acb-1f8e-407a-80fe-c424c6ee2861@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=jonas.oberhauser@huaweicloud.com \
--cc=josh@joshtriplett.org \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkmm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=maged.michael@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=neeraj.upadhyay@amd.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--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: 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.