Thread (13 messages) 13 messages, 3 authors, 2016-06-10

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

From: Michael Ellerman <mpe@ellerman.id.au>
Date: 2016-06-09 12:23:39
Also in: lkml

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:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help