futex: replace bare barrier() with a READ_ONCE()

Commit e91467ecd1ef ("bug in futex unqueue_me") introduces a barrier() in unqueue_me(), to address below problem.

The scenario is like this:

====================
original code:

retry:

       lock_ptr = q->lock_ptr;
       if (lock_ptr != 0)  {
                  spin_lock(lock_ptr)
                  if (unlikely(lock_ptr != q->lock_ptr)) {
                        spin_unlock(lock_ptr);
                         goto retry;
                  }
                   ...
       }

====================
s390x generates code that is equivalent to:

retry:

       if (q->lock_ptr != 0)  {
                  spin_lock(q->lock_ptr)
                  if (unlikely(lock_ptr != q->lock_ptr)) {
                        spin_unlock(lock_ptr);
                         goto retry;
                  }
                   ...
       }

since q->lock_ptr might change between test of non-nullness and spin_lock(), the double load may lead to problem. So that commit use a barrier() to prevent this.

This patch replaces this bare barrier() with a READ_ONCE().

The reasons are:

1) READ_ONCE() is a more weak form of barrier() that affect only the specific accesses, while barrier() is a more general compiler level memroy barrier.

2) READ_ONCE() which could be more informative by its name, while a bare barrier() without comment leads to quite a bit of perplexity.

3) READ_ONCE() _might_ prevent more _theoretical_ "optimizations" by the compiler:

The above retry logic is effectively the same as:

	while (lock_ptr = READ_ONCE(q->lock_ptr)) {
                   spin_lock(lock_ptr)
                   if (unlikely(lock_ptr != q->lock_ptr)) {
                         spin_unlock(lock_ptr);
                   }

                   ...
         }

If without the READ_ONCE, the compiler _might_ optimize the load of q->lock_ptr out of the test satement, which will also lead to the same pointer aliasing problem.

For why do compiler might do this, here is a snippet quoted from Documentation/memory-barriers.txt:

   |(*) The compiler is within its rights to reload a variable, for example,
   |    in cases where high register pressure prevents the compiler from
   |    keeping all data of interest in registers.  The compiler might
   |    therefore optimize the variable 'tmp' out of our previous example:
   |
   |     while (tmp = a)
   |         do_something_with(tmp);
   |
   |    This could result in the following code, which is perfectly safe in
   |    single-threaded code, but can be fatal in concurrent code:
   |
   |     while (a)
   |         do_something_with(a);
   |
   |    For example, the optimized version of this code could result in

   |    passing a zero to do_something_with() in the case where the variable
   |    a was modified by some other CPU between the "while" statement and
   |    the call to do_something_with().
   |
   |    Again, use READ_ONCE() to prevent the compiler from doing this:
   |
   |    while (tmp = READ_ONCE(a))
   |         do_something_with(tmp);

Suggested-by Darren Hart <[email protected]>

Signed-off-by Jianyu Zhan <[email protected]>

---
v1->v2:
According to suggestion by Darren Hart, revise the commit log to justify the replacement.

I also cc'ed the s390 maintainers, if they could help provide assembly code after this patch to prove the correctness, that would be better.

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

kernel/futex.c +0 -0

index 5d6ce64..6796084 100644
@@ -1927,8 +1927,13 @@ static int unqueue_me(struct futex_q *q)
 

kernel/futex.c +1 -0

+	lock_ptr = READ_ONCE(q->lock_ptr);
 	if (lock_ptr != NULL) {
 		spin_lock(lock_ptr);
 		/*

That change makes sense. I did the original barrier back in 2006 (could you cc me next time?)

ACCESS_ONCE or READ_ONCE was not available at that time and its now the better way.

This is not an s390 specific problem, it was just triggered there as the gcc cost model considered the memory read as cheap as a register read.

Maybe simplify the comment to something like

        /* Prevent the compiler to read lock_ptr twice (if and spin_lock) */

Quoted 1 line · Christian Borntraeger

That change makes sense. I did the original barrier back in 2006 (could you cc me next time?)

Sorry for that, I thought get_maintainer.pl would had spit the original author's email, but apparently it didn't :(

Quoted 3 lines

ACCESS_ONCE or READ_ONCE was not available at that time and its now the better way.

Quoted 3 lines

This is not an s390 specific problem, it was just triggered there as the gcc cost model considered the memory read as cheap as a register read.

Thanks for the clarification.

3) READ_ONCE() _might_ prevent more _theoretical_ "optimizations" by the compiler:

The above retry logic is effectively the same as:

	while (lock_ptr = READ_ONCE(q->lock_ptr)) {
                   spin_lock(lock_ptr)