On Wed, Dec 03, 2014 at 11:30:15PM +0100, Christian Borntraeger wrote: > ACCESS_ONCE does not work reliably on non-scalar types. For > example gcc 4.6 and 4.7 might remove the volatile tag for such > accesses during the SRA (scalar replacement of aggregates) step > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145) > > Change the spinlock code to replace ACCESS_ONCE with READ_ONCE. > > Signed-off-by: Christian Borntraeger <[email protected]>
Acked-by: Paul E. McKenney <[email protected]> > --- > arch/x86/include/asm/spinlock.h | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/include/asm/spinlock.h b/arch/x86/include/asm/spinlock.h > index 9295016..12a69b4 100644 > --- a/arch/x86/include/asm/spinlock.h > +++ b/arch/x86/include/asm/spinlock.h > @@ -92,7 +92,7 @@ static __always_inline void arch_spin_lock(arch_spinlock_t > *lock) > unsigned count = SPIN_THRESHOLD; > > do { > - if (ACCESS_ONCE(lock->tickets.head) == inc.tail) > + if (READ_ONCE(lock->tickets.head) == inc.tail) > goto out; > cpu_relax(); > } while (--count); > @@ -105,7 +105,7 @@ static __always_inline int > arch_spin_trylock(arch_spinlock_t *lock) > { > arch_spinlock_t old, new; > > - old.tickets = ACCESS_ONCE(lock->tickets); > + old.tickets = READ_ONCE(lock->tickets); > if (old.tickets.head != (old.tickets.tail & ~TICKET_SLOWPATH_FLAG)) > return 0; > > @@ -162,14 +162,14 @@ static __always_inline void > arch_spin_unlock(arch_spinlock_t *lock) > > static inline int arch_spin_is_locked(arch_spinlock_t *lock) > { > - struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); > + struct __raw_tickets tmp = READ_ONCE(lock->tickets); > > return tmp.tail != tmp.head; > } > > static inline int arch_spin_is_contended(arch_spinlock_t *lock) > { > - struct __raw_tickets tmp = ACCESS_ONCE(lock->tickets); > + struct __raw_tickets tmp = READ_ONCE(lock->tickets); > > return (__ticket_t)(tmp.tail - tmp.head) > TICKET_LOCK_INC; > } > -- > 1.9.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
