Re: [PATCH 4/8] x86/spinlock: Leftover conversion ACCESS_ONCE-READ_ONCE

2015-01-15 Thread Oleg Nesterov
On 01/15, Christian Borntraeger wrote:

 Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
  On 01/15, Christian Borntraeger wrote:
 
  --- a/arch/x86/include/asm/spinlock.h
  +++ b/arch/x86/include/asm/spinlock.h
  @@ -186,7 +186,7 @@ static inline void 
  arch_spin_unlock_wait(arch_spinlock_t *lock)
 __ticket_t head = ACCESS_ONCE(lock-tickets.head);
 
 for (;;) {
  -  struct __raw_tickets tmp = ACCESS_ONCE(lock-tickets);
  +  struct __raw_tickets tmp = READ_ONCE(lock-tickets);
 
  Agreed, but what about another ACCESS_ONCE() above?
 
  Oleg.

 tickets.head is a scalar type, so ACCESS_ONCE does work fine with gcc 4.6/4.7.
 My goal was to convert all accesses on non-scalar types

I understand, but READ_ONCE(lock-tickets.head) looks better anyway and
arch_spin_lock() already use READ_ONCE() for this.

So why we should keep the last ACCESS_ONCE() in spinlock.h ? Just to make
another cosmetic cleanup which touches the same function later?

Oleg.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/8] x86/spinlock: Leftover conversion ACCESS_ONCE-READ_ONCE

2015-01-15 Thread Christian Borntraeger
Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
 On 01/15, Christian Borntraeger wrote:

 --- a/arch/x86/include/asm/spinlock.h
 +++ b/arch/x86/include/asm/spinlock.h
 @@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t 
 *lock)
  __ticket_t head = ACCESS_ONCE(lock-tickets.head);
  
  for (;;) {
 -struct __raw_tickets tmp = ACCESS_ONCE(lock-tickets);
 +struct __raw_tickets tmp = READ_ONCE(lock-tickets);
 
 Agreed, but what about another ACCESS_ONCE() above?
 
 Oleg.
 

tickets.head is a scalar type, so ACCESS_ONCE does work fine with gcc 4.6/4.7.
My goal was to convert all accesses on non-scalar types as until 
kernel: tighten rules for ACCESS ONCE is merged because anything else would be
a Whac-a-mole like adventure (I learned that during the last round in next: all
conversions in this series fix up changes made during this merge window)

We probably going to do a bigger bunch of bulk conversion later on when 
kernel: tighten rules for ACCESS ONCE prevents new problems.

Makes sense?

Christian

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/8] x86/spinlock: Leftover conversion ACCESS_ONCE-READ_ONCE

2015-01-15 Thread Oleg Nesterov
On 01/15, Christian Borntraeger wrote:

 --- a/arch/x86/include/asm/spinlock.h
 +++ b/arch/x86/include/asm/spinlock.h
 @@ -186,7 +186,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t 
 *lock)
   __ticket_t head = ACCESS_ONCE(lock-tickets.head);
  
   for (;;) {
 - struct __raw_tickets tmp = ACCESS_ONCE(lock-tickets);
 + struct __raw_tickets tmp = READ_ONCE(lock-tickets);

Agreed, but what about another ACCESS_ONCE() above?

Oleg.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/8] x86/spinlock: Leftover conversion ACCESS_ONCE-READ_ONCE

2015-01-15 Thread Christian Borntraeger
Am 15.01.2015 um 21:01 schrieb Oleg Nesterov:
 On 01/15, Christian Borntraeger wrote:

 Am 15.01.2015 um 20:38 schrieb Oleg Nesterov:
 On 01/15, Christian Borntraeger wrote:

 --- a/arch/x86/include/asm/spinlock.h
 +++ b/arch/x86/include/asm/spinlock.h
 @@ -186,7 +186,7 @@ static inline void 
 arch_spin_unlock_wait(arch_spinlock_t *lock)
__ticket_t head = ACCESS_ONCE(lock-tickets.head);

for (;;) {
 -  struct __raw_tickets tmp = ACCESS_ONCE(lock-tickets);
 +  struct __raw_tickets tmp = READ_ONCE(lock-tickets);

 Agreed, but what about another ACCESS_ONCE() above?

 Oleg.

 tickets.head is a scalar type, so ACCESS_ONCE does work fine with gcc 
 4.6/4.7.
 My goal was to convert all accesses on non-scalar types
 
 I understand, but READ_ONCE(lock-tickets.head) looks better anyway and
 arch_spin_lock() already use READ_ONCE() for this.
 
 So why we should keep the last ACCESS_ONCE() in spinlock.h ? Just to make
 another cosmetic cleanup which touches the same function later?

OK, I will change that one as well.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev