[lkml]   [2018]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH 4.4 31/87] futex: Replace barrier() in unqueue_me() with READ_ONCE()
4.4-stable review patch.  If anyone has any objections, please let me know.


From: Jianyu Zhan <>

commit 29b75eb2d56a714190a93d7be4525e617591077a upstream.

Commit e91467ecd1ef ("bug in futex unqueue_me") introduced a barrier() in
unqueue_me() to prevent the compiler from rereading the lock pointer which
might change after a check for NULL.

Replace the barrier() with a READ_ONCE() for the following reasons:

1) READ_ONCE() is a weaker form of barrier() that affects only the specific
load operation, while barrier() is a general compiler level memory barrier.
READ_ONCE() was not available at the time when the barrier was added.

2) Aside of that READ_ONCE() is descriptive and self explainatory while a
barrier without comment is not clear to the casual reader.

No functional change.

[ tglx: Massaged changelog ]

Signed-off-by: Jianyu Zhan <>
Acked-by: Christian Borntraeger <>
Acked-by: Darren Hart <>
Signed-off-by: Thomas Gleixner <>
Signed-off-by: Davidlohr Bueso <>
Signed-off-by: Greg Kroah-Hartman <>

kernel/futex.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -1939,8 +1939,12 @@ static int unqueue_me(struct futex_q *q)

/* In the common case we don't take the spinlock, which is nice. */
- lock_ptr = q->lock_ptr;
- barrier();
+ /*
+ * q->lock_ptr can change between this read and the following spin_lock.
+ * Use READ_ONCE to forbid the compiler from reloading q->lock_ptr and
+ * optimizing lock_ptr out of the logic below.
+ */
+ lock_ptr = READ_ONCE(q->lock_ptr);
if (lock_ptr != NULL) {

 \ /
  Last update: 2018-01-15 15:19    [W:0.587 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site