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
