[PATCH v3] powerpc: spinlock: Fix spin_unlock_wait()

Michael Ellerman mpe at ellerman.id.au
Thu Jun 9 22:23:28 AEST 2016


On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote:
> On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote:
>
> > > Ok; what tree does this go in? I have this dependent series which I'd
> > > like to get sorted and merged somewhere.
> > 
> > Ah sorry, I didn't realise. I was going to put it in my next (which doesn't
> > exist yet but hopefully will early next week).
> > 
> > I'll make a topic branch with just that commit based on rc2 or rc3?
> 
> Works for me; thanks!
 
Unfortunately the patch isn't 100%.

It's causing some of my machines to lock up hard, which isn't surprising when
you look at the generated code for the non-atomic spin loop:

  c00000000009af48:	7c 21 0b 78 	mr      r1,r1					# HMT_LOW
  c00000000009af4c:	40 9e ff fc 	bne     cr7,c00000000009af48 <.do_exit+0x6d8>

Which is a spin loop waiting for a result in cr7, but with no comparison.

The problem seems to be that we did:

@@ -184,7 +184,7 @@ static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
 	if (arch_spin_value_unlocked(lock_val))
 		goto out;
 
-	while (lock->slock) {
+	while (!arch_spin_value_unlocked(*lock)) {
 		HMT_low();
 		if (SHARED_PROCESSOR)
 			__spin_yield(lock);

Which seems to be hiding the fact that lock->slock is volatile from the
compiler, even though arch_spin_value_unlocked() is inline. Not sure if that's
our bug or gcc's.

Will sleep on it.

cheers



More information about the Linuxppc-dev mailing list