lkml.org 
[lkml]   [2016]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectRe: [PATCH v3] powerpc: spinlock: Fix spin_unlock_wait()
From
Date
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

\
 
 \ /
  Last update: 2016-06-09 15:01    [W:0.076 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site