diff options
| author | Peter Zijlstra <peterz@infradead.org> | 2016-05-20 18:04:36 +0200 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2016-06-01 12:15:53 -0700 |
| commit | 035688290a740745adf9daff65bceac8b70e8732 (patch) | |
| tree | e8ac6811621661dfe3e4d77ef31c280c9d55dd51 /kernel/module_signing.c | |
| parent | df8ad62006f452ee4902e216e955f1a142cf144f (diff) | |
locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()
commit 54cf809b9512be95f53ed4a5e3b631d1ac42f0fa upstream.
Similar to commits:
51d7d5205d33 ("powerpc: Add smp_mb() to arch_spin_is_locked()")
d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers")
qspinlock suffers from the fact that the _Q_LOCKED_VAL store is
unordered inside the ACQUIRE of the lock.
And while this is not a problem for the regular mutual exclusive
critical section usage of spinlocks, it breaks creative locking like:
spin_lock(A) spin_lock(B)
spin_unlock_wait(B) if (!spin_is_locked(A))
do_something() do_something()
In that both CPUs can end up running do_something at the same time,
because our _Q_LOCKED_VAL store can drop past the spin_unlock_wait()
spin_is_locked() loads (even on x86!!).
To avoid making the normal case slower, add smp_mb()s to the less used
spin_unlock_wait() / spin_is_locked() side of things to avoid this
problem.
Reported-and-tested-by: Davidlohr Bueso <dave@stgolabs.net>
Reported-by: Giovanni Gherdovich <ggherdovich@suse.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'kernel/module_signing.c')
0 files changed, 0 insertions, 0 deletions