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:2.916 / U:0.052 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site