2015-04-25 01:56:30 +07:00
|
|
|
/*
|
|
|
|
* Queued spinlock
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
|
|
|
|
* (C) Copyright 2013-2014 Red Hat, Inc.
|
|
|
|
* (C) Copyright 2015 Intel Corp.
|
2015-11-10 07:09:21 +07:00
|
|
|
* (C) Copyright 2015 Hewlett-Packard Enterprise Development LP
|
2015-04-25 01:56:30 +07:00
|
|
|
*
|
2015-11-10 07:09:21 +07:00
|
|
|
* Authors: Waiman Long <waiman.long@hpe.com>
|
2015-04-25 01:56:30 +07:00
|
|
|
* Peter Zijlstra <peterz@infradead.org>
|
|
|
|
*/
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
#ifndef _GEN_PV_LOCK_SLOWPATH
|
|
|
|
|
2015-04-25 01:56:30 +07:00
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/bug.h>
|
|
|
|
#include <linux/cpumask.h>
|
|
|
|
#include <linux/percpu.h>
|
|
|
|
#include <linux/hardirq.h>
|
|
|
|
#include <linux/mutex.h>
|
2017-07-08 02:56:58 +07:00
|
|
|
#include <linux/prefetch.h>
|
2015-04-25 01:56:34 +07:00
|
|
|
#include <asm/byteorder.h>
|
2015-04-25 01:56:30 +07:00
|
|
|
#include <asm/qspinlock.h>
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The basic principle of a queue-based spinlock can best be understood
|
|
|
|
* by studying a classic queue-based spinlock implementation called the
|
|
|
|
* MCS lock. The paper below provides a good description for this kind
|
|
|
|
* of lock.
|
|
|
|
*
|
|
|
|
* http://www.cise.ufl.edu/tr/DOC/REP-1992-71.pdf
|
|
|
|
*
|
|
|
|
* This queued spinlock implementation is based on the MCS lock, however to make
|
|
|
|
* it fit the 4 bytes we assume spinlock_t to be, and preserve its existing
|
|
|
|
* API, we must modify it somehow.
|
|
|
|
*
|
|
|
|
* In particular; where the traditional MCS lock consists of a tail pointer
|
|
|
|
* (8 bytes) and needs the next pointer (another 8 bytes) of its own node to
|
|
|
|
* unlock the next pending (next->locked), we compress both these: {tail,
|
|
|
|
* next->locked} into a single u32 value.
|
|
|
|
*
|
|
|
|
* Since a spinlock disables recursion of its own context and there is a limit
|
|
|
|
* to the contexts that can nest; namely: task, softirq, hardirq, nmi. As there
|
|
|
|
* are at most 4 nesting levels, it can be encoded by a 2-bit number. Now
|
|
|
|
* we can encode the tail by combining the 2-bit nesting level with the cpu
|
|
|
|
* number. With one byte for the lock value and 3 bytes for the tail, only a
|
|
|
|
* 32-bit word is now needed. Even though we only need 1 bit for the lock,
|
|
|
|
* we extend it to a full byte to achieve better performance for architectures
|
|
|
|
* that support atomic byte write.
|
|
|
|
*
|
|
|
|
* We also change the first spinner to spin on the lock bit instead of its
|
|
|
|
* node; whereby avoiding the need to carry a node from lock to unlock, and
|
|
|
|
* preserving existing lock API. This also makes the unlock code simpler and
|
|
|
|
* faster.
|
2015-04-25 01:56:34 +07:00
|
|
|
*
|
|
|
|
* N.B. The current implementation only supports architectures that allow
|
|
|
|
* atomic operations on smaller 8-bit and 16-bit data types.
|
|
|
|
*
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "mcs_spinlock.h"
|
|
|
|
|
2015-04-25 01:56:37 +07:00
|
|
|
#ifdef CONFIG_PARAVIRT_SPINLOCKS
|
|
|
|
#define MAX_NODES 8
|
|
|
|
#else
|
|
|
|
#define MAX_NODES 4
|
|
|
|
#endif
|
|
|
|
|
2018-04-26 17:34:17 +07:00
|
|
|
/*
|
|
|
|
* The pending bit spinning loop count.
|
|
|
|
* This heuristic is used to limit the number of lockword accesses
|
|
|
|
* made by atomic_cond_read_relaxed when waiting for the lock to
|
|
|
|
* transition out of the "== _Q_PENDING_VAL" state. We don't spin
|
|
|
|
* indefinitely because there's no guarantee that we'll make forward
|
|
|
|
* progress.
|
|
|
|
*/
|
|
|
|
#ifndef _Q_PENDING_LOOPS
|
|
|
|
#define _Q_PENDING_LOOPS 1
|
|
|
|
#endif
|
|
|
|
|
2015-04-25 01:56:30 +07:00
|
|
|
/*
|
|
|
|
* Per-CPU queue node structures; we can never have more than 4 nested
|
|
|
|
* contexts: task, softirq, hardirq, nmi.
|
|
|
|
*
|
|
|
|
* Exactly fits one 64-byte cacheline on a 64-bit architecture.
|
2015-04-25 01:56:37 +07:00
|
|
|
*
|
|
|
|
* PV doubles the storage and uses the second cacheline for PV state.
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2015-04-25 01:56:37 +07:00
|
|
|
static DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, mcs_nodes[MAX_NODES]);
|
2015-04-25 01:56:30 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We must be able to distinguish between no-tail and the tail at 0:0,
|
|
|
|
* therefore increment the cpu number by one.
|
|
|
|
*/
|
|
|
|
|
2016-06-08 14:12:30 +07:00
|
|
|
static inline __pure u32 encode_tail(int cpu, int idx)
|
2015-04-25 01:56:30 +07:00
|
|
|
{
|
|
|
|
u32 tail;
|
|
|
|
|
|
|
|
#ifdef CONFIG_DEBUG_SPINLOCK
|
|
|
|
BUG_ON(idx > 3);
|
|
|
|
#endif
|
|
|
|
tail = (cpu + 1) << _Q_TAIL_CPU_OFFSET;
|
|
|
|
tail |= idx << _Q_TAIL_IDX_OFFSET; /* assume < 4 */
|
|
|
|
|
|
|
|
return tail;
|
|
|
|
}
|
|
|
|
|
2016-06-08 14:12:30 +07:00
|
|
|
static inline __pure struct mcs_spinlock *decode_tail(u32 tail)
|
2015-04-25 01:56:30 +07:00
|
|
|
{
|
|
|
|
int cpu = (tail >> _Q_TAIL_CPU_OFFSET) - 1;
|
|
|
|
int idx = (tail & _Q_TAIL_IDX_MASK) >> _Q_TAIL_IDX_OFFSET;
|
|
|
|
|
|
|
|
return per_cpu_ptr(&mcs_nodes[idx], cpu);
|
|
|
|
}
|
|
|
|
|
2015-04-25 01:56:32 +07:00
|
|
|
#define _Q_LOCKED_PENDING_MASK (_Q_LOCKED_MASK | _Q_PENDING_MASK)
|
|
|
|
|
2015-04-25 01:56:35 +07:00
|
|
|
#if _Q_PENDING_BITS == 8
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
/**
|
|
|
|
* clear_pending - clear the pending bit.
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
*
|
|
|
|
* *,1,* -> *,0,*
|
|
|
|
*/
|
|
|
|
static __always_inline void clear_pending(struct qspinlock *lock)
|
|
|
|
{
|
|
|
|
WRITE_ONCE(lock->pending, 0);
|
|
|
|
}
|
|
|
|
|
2015-04-25 01:56:34 +07:00
|
|
|
/**
|
|
|
|
* clear_pending_set_locked - take ownership and clear the pending bit.
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
*
|
|
|
|
* *,1,0 -> *,0,1
|
|
|
|
*
|
|
|
|
* Lock stealing is not allowed if this function is used.
|
|
|
|
*/
|
|
|
|
static __always_inline void clear_pending_set_locked(struct qspinlock *lock)
|
|
|
|
{
|
2018-04-26 17:34:16 +07:00
|
|
|
WRITE_ONCE(lock->locked_pending, _Q_LOCKED_VAL);
|
2015-04-25 01:56:34 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* xchg_tail - Put in the new queue tail code word & retrieve previous one
|
|
|
|
* @lock : Pointer to queued spinlock structure
|
|
|
|
* @tail : The new queue tail code word
|
|
|
|
* Return: The previous queue tail code word
|
|
|
|
*
|
2017-10-10 01:22:50 +07:00
|
|
|
* xchg(lock, tail), which heads an address dependency
|
2015-04-25 01:56:34 +07:00
|
|
|
*
|
|
|
|
* p,*,* -> n,*,* ; prev = xchg(lock, node)
|
|
|
|
*/
|
|
|
|
static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
|
|
|
|
{
|
2015-11-10 07:09:21 +07:00
|
|
|
/*
|
2018-04-26 17:34:25 +07:00
|
|
|
* We can use relaxed semantics since the caller ensures that the
|
|
|
|
* MCS node is properly initialized before updating the tail.
|
2015-11-10 07:09:21 +07:00
|
|
|
*/
|
2018-04-26 17:34:25 +07:00
|
|
|
return (u32)xchg_relaxed(&lock->tail,
|
2015-11-10 07:09:21 +07:00
|
|
|
tail >> _Q_TAIL_OFFSET) << _Q_TAIL_OFFSET;
|
2015-04-25 01:56:34 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* _Q_PENDING_BITS == 8 */
|
|
|
|
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
/**
|
|
|
|
* clear_pending - clear the pending bit.
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
*
|
|
|
|
* *,1,* -> *,0,*
|
|
|
|
*/
|
|
|
|
static __always_inline void clear_pending(struct qspinlock *lock)
|
|
|
|
{
|
|
|
|
atomic_andnot(_Q_PENDING_VAL, &lock->val);
|
|
|
|
}
|
|
|
|
|
2015-04-25 01:56:33 +07:00
|
|
|
/**
|
|
|
|
* clear_pending_set_locked - take ownership and clear the pending bit.
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
*
|
|
|
|
* *,1,0 -> *,0,1
|
|
|
|
*/
|
|
|
|
static __always_inline void clear_pending_set_locked(struct qspinlock *lock)
|
|
|
|
{
|
|
|
|
atomic_add(-_Q_PENDING_VAL + _Q_LOCKED_VAL, &lock->val);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* xchg_tail - Put in the new queue tail code word & retrieve previous one
|
|
|
|
* @lock : Pointer to queued spinlock structure
|
|
|
|
* @tail : The new queue tail code word
|
|
|
|
* Return: The previous queue tail code word
|
|
|
|
*
|
|
|
|
* xchg(lock, tail)
|
|
|
|
*
|
|
|
|
* p,*,* -> n,*,* ; prev = xchg(lock, node)
|
|
|
|
*/
|
|
|
|
static __always_inline u32 xchg_tail(struct qspinlock *lock, u32 tail)
|
|
|
|
{
|
|
|
|
u32 old, new, val = atomic_read(&lock->val);
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
new = (val & _Q_LOCKED_PENDING_MASK) | tail;
|
2015-11-10 07:09:21 +07:00
|
|
|
/*
|
2018-04-26 17:34:25 +07:00
|
|
|
* We can use relaxed semantics since the caller ensures that
|
|
|
|
* the MCS node is properly initialized before updating the
|
|
|
|
* tail.
|
2015-11-10 07:09:21 +07:00
|
|
|
*/
|
2018-04-26 17:34:25 +07:00
|
|
|
old = atomic_cmpxchg_relaxed(&lock->val, val, new);
|
2015-04-25 01:56:33 +07:00
|
|
|
if (old == val)
|
|
|
|
break;
|
|
|
|
|
|
|
|
val = old;
|
|
|
|
}
|
|
|
|
return old;
|
|
|
|
}
|
2015-04-25 01:56:34 +07:00
|
|
|
#endif /* _Q_PENDING_BITS == 8 */
|
2015-04-25 01:56:33 +07:00
|
|
|
|
2015-04-25 01:56:35 +07:00
|
|
|
/**
|
|
|
|
* set_locked - Set the lock bit and own the lock
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
*
|
|
|
|
* *,*,0 -> *,0,1
|
|
|
|
*/
|
|
|
|
static __always_inline void set_locked(struct qspinlock *lock)
|
|
|
|
{
|
2018-04-26 17:34:16 +07:00
|
|
|
WRITE_ONCE(lock->locked, _Q_LOCKED_VAL);
|
2015-04-25 01:56:35 +07:00
|
|
|
}
|
|
|
|
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate the native code for queued_spin_unlock_slowpath(); provide NOPs for
|
|
|
|
* all the PV callbacks.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static __always_inline void __pv_init_node(struct mcs_spinlock *node) { }
|
2015-11-10 07:09:27 +07:00
|
|
|
static __always_inline void __pv_wait_node(struct mcs_spinlock *node,
|
|
|
|
struct mcs_spinlock *prev) { }
|
2015-07-12 03:36:52 +07:00
|
|
|
static __always_inline void __pv_kick_node(struct qspinlock *lock,
|
|
|
|
struct mcs_spinlock *node) { }
|
2015-11-11 04:18:56 +07:00
|
|
|
static __always_inline u32 __pv_wait_head_or_lock(struct qspinlock *lock,
|
|
|
|
struct mcs_spinlock *node)
|
|
|
|
{ return 0; }
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
#define pv_enabled() false
|
|
|
|
|
|
|
|
#define pv_init_node __pv_init_node
|
|
|
|
#define pv_wait_node __pv_wait_node
|
|
|
|
#define pv_kick_node __pv_kick_node
|
2015-11-11 04:18:56 +07:00
|
|
|
#define pv_wait_head_or_lock __pv_wait_head_or_lock
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
#ifdef CONFIG_PARAVIRT_SPINLOCKS
|
|
|
|
#define queued_spin_lock_slowpath native_queued_spin_lock_slowpath
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#endif /* _GEN_PV_LOCK_SLOWPATH */
|
|
|
|
|
2015-04-25 01:56:30 +07:00
|
|
|
/**
|
|
|
|
* queued_spin_lock_slowpath - acquire the queued spinlock
|
|
|
|
* @lock: Pointer to queued spinlock structure
|
|
|
|
* @val: Current value of the queued spinlock 32-bit word
|
|
|
|
*
|
2015-04-25 01:56:32 +07:00
|
|
|
* (queue tail, pending bit, lock value)
|
2015-04-25 01:56:30 +07:00
|
|
|
*
|
2015-04-25 01:56:32 +07:00
|
|
|
* fast : slow : unlock
|
|
|
|
* : :
|
|
|
|
* uncontended (0,0,0) -:--> (0,0,1) ------------------------------:--> (*,*,0)
|
|
|
|
* : | ^--------.------. / :
|
|
|
|
* : v \ \ | :
|
|
|
|
* pending : (0,1,1) +--> (0,1,0) \ | :
|
|
|
|
* : | ^--' | | :
|
|
|
|
* : v | | :
|
|
|
|
* uncontended : (n,x,y) +--> (n,0,0) --' | :
|
|
|
|
* queue : | ^--' | :
|
|
|
|
* : v | :
|
|
|
|
* contended : (*,x,y) +--> (*,0,0) ---> (*,0,1) -' :
|
|
|
|
* queue : ^--' :
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
|
|
|
void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
|
|
|
|
{
|
|
|
|
struct mcs_spinlock *prev, *next, *node;
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
u32 old, tail;
|
2015-04-25 01:56:30 +07:00
|
|
|
int idx;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(CONFIG_NR_CPUS >= (1U << _Q_TAIL_CPU_BITS));
|
|
|
|
|
2015-04-25 01:56:37 +07:00
|
|
|
if (pv_enabled())
|
|
|
|
goto queue;
|
|
|
|
|
2015-09-04 22:25:23 +07:00
|
|
|
if (virt_spin_lock(lock))
|
2015-04-25 01:56:36 +07:00
|
|
|
return;
|
|
|
|
|
2015-04-25 01:56:32 +07:00
|
|
|
/*
|
2018-04-26 17:34:17 +07:00
|
|
|
* Wait for in-progress pending->locked hand-overs with a bounded
|
|
|
|
* number of spins so that we guarantee forward progress.
|
2015-04-25 01:56:32 +07:00
|
|
|
*
|
|
|
|
* 0,1,0 -> 0,0,1
|
|
|
|
*/
|
|
|
|
if (val == _Q_PENDING_VAL) {
|
2018-04-26 17:34:17 +07:00
|
|
|
int cnt = _Q_PENDING_LOOPS;
|
|
|
|
val = atomic_cond_read_relaxed(&lock->val,
|
|
|
|
(VAL != _Q_PENDING_VAL) || !cnt--);
|
2015-04-25 01:56:32 +07:00
|
|
|
}
|
|
|
|
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
/*
|
|
|
|
* If we observe any contention; queue.
|
|
|
|
*/
|
|
|
|
if (val & ~_Q_LOCKED_MASK)
|
|
|
|
goto queue;
|
|
|
|
|
2015-04-25 01:56:32 +07:00
|
|
|
/*
|
|
|
|
* trylock || pending
|
|
|
|
*
|
|
|
|
* 0,0,0 -> 0,0,1 ; trylock
|
|
|
|
* 0,0,1 -> 0,1,1 ; pending
|
|
|
|
*/
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
val = atomic_fetch_or_acquire(_Q_PENDING_VAL, &lock->val);
|
|
|
|
if (!(val & ~_Q_LOCKED_MASK)) {
|
2015-04-25 01:56:32 +07:00
|
|
|
/*
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
* We're pending, wait for the owner to go away.
|
|
|
|
*
|
|
|
|
* *,1,1 -> *,1,0
|
|
|
|
*
|
|
|
|
* this wait loop must be a load-acquire such that we match the
|
|
|
|
* store-release that clears the locked bit and create lock
|
|
|
|
* sequentiality; this is because not all
|
|
|
|
* clear_pending_set_locked() implementations imply full
|
|
|
|
* barriers.
|
2015-04-25 01:56:32 +07:00
|
|
|
*/
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
if (val & _Q_LOCKED_MASK) {
|
2018-04-26 17:34:21 +07:00
|
|
|
atomic_cond_read_acquire(&lock->val,
|
|
|
|
!(VAL & _Q_LOCKED_MASK));
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
}
|
2015-04-25 01:56:32 +07:00
|
|
|
|
2015-11-10 07:09:21 +07:00
|
|
|
/*
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
* take ownership and clear the pending bit.
|
|
|
|
*
|
|
|
|
* *,1,0 -> *,0,1
|
2015-11-10 07:09:21 +07:00
|
|
|
*/
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
clear_pending_set_locked(lock);
|
2015-04-25 01:56:32 +07:00
|
|
|
return;
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
}
|
2015-04-25 01:56:32 +07:00
|
|
|
|
|
|
|
/*
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
* If pending was clear but there are waiters in the queue, then
|
|
|
|
* we need to undo our setting of pending before we queue ourselves.
|
2015-04-25 01:56:32 +07:00
|
|
|
*/
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
if (!(val & _Q_PENDING_MASK))
|
|
|
|
clear_pending(lock);
|
2015-04-25 01:56:32 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* End of pending bit optimistic spinning and beginning of MCS
|
|
|
|
* queuing.
|
|
|
|
*/
|
|
|
|
queue:
|
2015-04-25 01:56:30 +07:00
|
|
|
node = this_cpu_ptr(&mcs_nodes[0]);
|
|
|
|
idx = node->count++;
|
|
|
|
tail = encode_tail(smp_processor_id(), idx);
|
|
|
|
|
|
|
|
node += idx;
|
2018-02-13 20:22:57 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that we increment the head node->count before initialising
|
|
|
|
* the actual node. If the compiler is kind enough to reorder these
|
|
|
|
* stores, then an IRQ could overwrite our assignments.
|
|
|
|
*/
|
|
|
|
barrier();
|
|
|
|
|
2015-04-25 01:56:30 +07:00
|
|
|
node->locked = 0;
|
|
|
|
node->next = NULL;
|
2015-04-25 01:56:37 +07:00
|
|
|
pv_init_node(node);
|
2015-04-25 01:56:30 +07:00
|
|
|
|
|
|
|
/*
|
2015-04-25 01:56:33 +07:00
|
|
|
* We touched a (possibly) cold cacheline in the per-cpu queue node;
|
|
|
|
* attempt the trylock once more in the hope someone let go while we
|
|
|
|
* weren't watching.
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2015-04-25 01:56:33 +07:00
|
|
|
if (queued_spin_trylock(lock))
|
|
|
|
goto release;
|
2015-04-25 01:56:30 +07:00
|
|
|
|
|
|
|
/*
|
2018-04-26 17:34:25 +07:00
|
|
|
* Ensure that the initialisation of @node is complete before we
|
|
|
|
* publish the updated tail via xchg_tail() and potentially link
|
|
|
|
* @node into the waitqueue via WRITE_ONCE(prev->next, node) below.
|
|
|
|
*/
|
|
|
|
smp_wmb();
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Publish the updated tail.
|
2015-04-25 01:56:33 +07:00
|
|
|
* We have already touched the queueing cacheline; don't bother with
|
|
|
|
* pending stuff.
|
|
|
|
*
|
|
|
|
* p,*,* -> n,*,*
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2015-04-25 01:56:33 +07:00
|
|
|
old = xchg_tail(lock, tail);
|
2015-11-10 07:09:23 +07:00
|
|
|
next = NULL;
|
2015-04-25 01:56:30 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* if there was a previous node; link it and wait until reaching the
|
|
|
|
* head of the waitqueue.
|
|
|
|
*/
|
2015-04-25 01:56:33 +07:00
|
|
|
if (old & _Q_TAIL_MASK) {
|
2015-04-25 01:56:30 +07:00
|
|
|
prev = decode_tail(old);
|
2018-02-13 20:22:56 +07:00
|
|
|
|
2018-04-26 17:34:25 +07:00
|
|
|
/* Link @node into the waitqueue. */
|
|
|
|
WRITE_ONCE(prev->next, node);
|
2015-04-25 01:56:30 +07:00
|
|
|
|
2015-11-10 07:09:27 +07:00
|
|
|
pv_wait_node(node, prev);
|
2015-04-25 01:56:30 +07:00
|
|
|
arch_mcs_spin_lock_contended(&node->locked);
|
2015-11-10 07:09:22 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* While waiting for the MCS lock, the next pointer may have
|
|
|
|
* been set by another lock waiter. We optimistically load
|
|
|
|
* the next pointer & prefetch the cacheline for writing
|
|
|
|
* to reduce latency in the upcoming MCS unlock operation.
|
|
|
|
*/
|
|
|
|
next = READ_ONCE(node->next);
|
|
|
|
if (next)
|
|
|
|
prefetchw(next);
|
2015-04-25 01:56:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2015-04-25 01:56:32 +07:00
|
|
|
* we're at the head of the waitqueue, wait for the owner & pending to
|
|
|
|
* go away.
|
2015-04-25 01:56:30 +07:00
|
|
|
*
|
2015-04-25 01:56:32 +07:00
|
|
|
* *,x,y -> *,0,0
|
2015-04-25 01:56:35 +07:00
|
|
|
*
|
|
|
|
* this wait loop must use a load-acquire such that we match the
|
|
|
|
* store-release that clears the locked bit and create lock
|
|
|
|
* sequentiality; this is because the set_locked() function below
|
|
|
|
* does not imply a full barrier.
|
|
|
|
*
|
2015-11-11 04:18:56 +07:00
|
|
|
* The PV pv_wait_head_or_lock function, if active, will acquire
|
|
|
|
* the lock and return a non-zero value. So we have to skip the
|
2018-04-26 17:34:21 +07:00
|
|
|
* atomic_cond_read_acquire() call. As the next PV queue head hasn't
|
|
|
|
* been designated yet, there is no way for the locked value to become
|
2015-11-11 04:18:56 +07:00
|
|
|
* _Q_SLOW_VAL. So both the set_locked() and the
|
|
|
|
* atomic_cmpxchg_relaxed() calls will be safe.
|
|
|
|
*
|
|
|
|
* If PV isn't active, 0 will be returned instead.
|
|
|
|
*
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2015-11-11 04:18:56 +07:00
|
|
|
if ((val = pv_wait_head_or_lock(lock, node)))
|
|
|
|
goto locked;
|
|
|
|
|
2018-04-26 17:34:21 +07:00
|
|
|
val = atomic_cond_read_acquire(&lock->val, !(VAL & _Q_LOCKED_PENDING_MASK));
|
2015-04-25 01:56:30 +07:00
|
|
|
|
2015-11-11 04:18:56 +07:00
|
|
|
locked:
|
2015-04-25 01:56:30 +07:00
|
|
|
/*
|
|
|
|
* claim the lock:
|
|
|
|
*
|
2015-04-25 01:56:32 +07:00
|
|
|
* n,0,0 -> 0,0,1 : lock, uncontended
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
* *,*,0 -> *,*,1 : lock, contended
|
2015-04-25 01:56:35 +07:00
|
|
|
*
|
locking/qspinlock: Remove unbounded cmpxchg() loop from locking slowpath
The qspinlock locking slowpath utilises a "pending" bit as a simple form
of an embedded test-and-set lock that can avoid the overhead of explicit
queuing in cases where the lock is held but uncontended. This bit is
managed using a cmpxchg() loop which tries to transition the uncontended
lock word from (0,0,0) -> (0,0,1) or (0,0,1) -> (0,1,1).
Unfortunately, the cmpxchg() loop is unbounded and lockers can be starved
indefinitely if the lock word is seen to oscillate between unlocked
(0,0,0) and locked (0,0,1). This could happen if concurrent lockers are
able to take the lock in the cmpxchg() loop without queuing and pass it
around amongst themselves.
This patch fixes the problem by unconditionally setting _Q_PENDING_VAL
using atomic_fetch_or, and then inspecting the old value to see whether
we need to spin on the current lock owner, or whether we now effectively
hold the lock. The tricky scenario is when concurrent lockers end up
queuing on the lock and the lock becomes available, causing us to see
a lockword of (n,0,0). With pending now set, simply queuing could lead
to deadlock as the head of the queue may not have observed the pending
flag being cleared. Conversely, if the head of the queue did observe
pending being cleared, then it could transition the lock from (n,0,0) ->
(0,0,1) meaning that any attempt to "undo" our setting of the pending
bit could race with a concurrent locker trying to set it.
We handle this race by preserving the pending bit when taking the lock
after reaching the head of the queue and leaving the tail entry intact
if we saw pending set, because we know that the tail is going to be
updated shortly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Waiman Long <longman@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: paulmck@linux.vnet.ibm.com
Link: http://lkml.kernel.org/r/1524738868-31318-6-git-send-email-will.deacon@arm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-04-26 17:34:19 +07:00
|
|
|
* If the queue head is the only one in the queue (lock value == tail)
|
|
|
|
* and nobody is pending, clear the tail code and grab the lock.
|
|
|
|
* Otherwise, we only need to grab the lock.
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2018-04-26 17:34:20 +07:00
|
|
|
|
2018-04-26 17:34:26 +07:00
|
|
|
/*
|
|
|
|
* In the PV case we might already have _Q_LOCKED_VAL set.
|
|
|
|
*
|
|
|
|
* The atomic_cond_read_acquire() call above has provided the
|
|
|
|
* necessary acquire semantics required for locking.
|
|
|
|
*/
|
|
|
|
if (((val & _Q_TAIL_MASK) == tail) &&
|
|
|
|
atomic_try_cmpxchg_relaxed(&lock->val, &val, _Q_LOCKED_VAL))
|
|
|
|
goto release; /* No contention */
|
2015-04-25 01:56:30 +07:00
|
|
|
|
2018-04-26 17:34:20 +07:00
|
|
|
/* Either somebody is queued behind us or _Q_PENDING_VAL is set */
|
|
|
|
set_locked(lock);
|
|
|
|
|
2015-04-25 01:56:30 +07:00
|
|
|
/*
|
2015-11-10 07:09:23 +07:00
|
|
|
* contended path; wait for next if not observed yet, release.
|
2015-04-25 01:56:30 +07:00
|
|
|
*/
|
2018-04-26 17:34:23 +07:00
|
|
|
if (!next)
|
|
|
|
next = smp_cond_load_relaxed(&node->next, (VAL));
|
2015-04-25 01:56:30 +07:00
|
|
|
|
2015-04-25 01:56:35 +07:00
|
|
|
arch_mcs_spin_unlock_contended(&next->locked);
|
2015-07-12 03:36:52 +07:00
|
|
|
pv_kick_node(lock, next);
|
2015-04-25 01:56:30 +07:00
|
|
|
|
|
|
|
release:
|
|
|
|
/*
|
|
|
|
* release the node
|
|
|
|
*/
|
2016-06-14 13:37:27 +07:00
|
|
|
__this_cpu_dec(mcs_nodes[0].count);
|
2015-04-25 01:56:30 +07:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(queued_spin_lock_slowpath);
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Generate the paravirt code for queued_spin_unlock_slowpath().
|
|
|
|
*/
|
|
|
|
#if !defined(_GEN_PV_LOCK_SLOWPATH) && defined(CONFIG_PARAVIRT_SPINLOCKS)
|
|
|
|
#define _GEN_PV_LOCK_SLOWPATH
|
|
|
|
|
|
|
|
#undef pv_enabled
|
|
|
|
#define pv_enabled() true
|
|
|
|
|
|
|
|
#undef pv_init_node
|
|
|
|
#undef pv_wait_node
|
|
|
|
#undef pv_kick_node
|
2015-11-11 04:18:56 +07:00
|
|
|
#undef pv_wait_head_or_lock
|
2015-04-25 01:56:37 +07:00
|
|
|
|
|
|
|
#undef queued_spin_lock_slowpath
|
|
|
|
#define queued_spin_lock_slowpath __pv_queued_spin_lock_slowpath
|
|
|
|
|
|
|
|
#include "qspinlock_paravirt.h"
|
|
|
|
#include "qspinlock.c"
|
|
|
|
|
|
|
|
#endif
|