locking: Implement an algorithm choice for Wound-Wait mutexes

Wait/Wound Deadlock-Proof Mutex Design

Wound/Wait Deadlock-Proof Mutex Design

======================================

Please read mutex-design.txt first, as it applies to wait/wound mutexes too.

younger task) unlocks all of the buffers that it has already locked, and then

tries again.

In the RDBMS literature this deadlock handling approach is called wait/die:

The older tasks waits until it can acquire the contended lock. The younger tasks

needs to back off and drop all the locks it is currently holding, i.e. the

younger task dies.

In the RDBMS literature, a reservation ticket is associated with a transaction.

and the deadlock handling approach is called Wait-Die. The name is based on

the actions of a locking thread when it encounters an already locked mutex.

If the transaction holding the lock is younger, the locking transaction waits.

If the transaction holding the lock is older, the locking transaction backs off

and dies. Hence Wait-Die.

There is also another algorithm called Wound-Wait:

If the transaction holding the lock is younger, the locking transaction

wounds the transaction holding the lock, requesting it to die.

If the transaction holding the lock is older, it waits for the other

transaction. Hence Wound-Wait.

The two algorithms are both fair in that a transaction will eventually succeed.

However, the Wound-Wait algorithm is typically stated to generate fewer backoffs

compared to Wait-Die, but is, on the other hand, associated with more work than

Wait-Die when recovering from a backoff. Wound-Wait is also a preemptive

algorithm in that transactions are wounded by other transactions, and that

requires a reliable way to pick up up the wounded condition and preempt the

running transaction. Note that this is not the same as process preemption. A

Wound-Wait transaction is considered preempted when it dies (returning

-EDEADLK) following a wound.

Concepts

--------

trying to acquire locks doesn't grab a new reservation id, but keeps the one it

acquired when starting the lock acquisition. This ticket is stored in the

acquire context. Furthermore the acquire context keeps track of debugging state

to catch w/w mutex interface abuse.

to catch w/w mutex interface abuse. An acquire context is representing a

transaction.

W/w class: In contrast to normal mutexes the lock class needs to be explicit for

w/w mutexes, since it is required to initialize the acquire context.

w/w mutexes, since it is required to initialize the acquire context. The lock

class also specifies what algorithm to use, Wound-Wait or Wait-Die.

Furthermore there are three different class of w/w lock acquire functions:

Usage

-----

The algorithm (Wait-Die vs Wound-Wait) is chosen by using either

DEFINE_WW_CLASS() (Wound-Wait) or DEFINE_WD_CLASS() (Wait-Die)

As a rough rule of thumb, use Wound-Wait iff you

expect the number of simultaneous competing transactions to be typically small,

and you want to reduce the number of rollbacks.

Three different ways to acquire locks within the same w/w class. Common

definitions for methods #1 and #2:

  We maintain the following invariants for the wait list:

  (1) Waiters with an acquire context are sorted by stamp order; waiters

      without an acquire context are interspersed in FIFO order.

  (2) Among waiters with contexts, only the first one can have other locks

      acquired already (ctx->acquired > 0). Note that this waiter may come

      after other waiters without contexts in the list.

  (2) For Wait-Die, among waiters with contexts, only the first one can have

      other locks acquired already (ctx->acquired > 0). Note that this waiter

      may come after other waiters without contexts in the list.

  The Wound-Wait preemption is implemented with a lazy-preemption scheme:

  The wounded status of the transaction is checked only when there is

  contention for a new lock and hence a true chance of deadlock. In that

  situation, if the transaction is wounded, it backs off, clears the

  wounded status and retries. A great benefit of implementing preemption in

  this way is that the wounded transaction can identify a contending lock to

  wait for before restarting the transaction. Just blindly restarting the

  transaction would likely make the transaction end up in a situation where

  it would have to back off again.

  In general, not much contention is expected. The locks are typically used to

  serialize access to resources for devices.

  serialize access to resources for devices, and optimization focus should

  therefore be directed towards the uncontended cases.

Lockdep:

  Special care has been taken to warn for as many cases of api abuse

 * write-side updates.

 */

DEFINE_WW_CLASS(reservation_ww_class);

DEFINE_WD_CLASS(reservation_ww_class);

EXPORT_SYMBOL(reservation_ww_class);

struct lock_class_key reservation_seqcount_class;

 * lists and lookup data structures.

 */

static DEFINE_WW_CLASS(crtc_ww_class);

static DEFINE_WD_CLASS(crtc_ww_class);

/**

 * drm_modeset_lock_all - take all modeset locks

 *

 * Wait/Die implementation:

 *  Copyright (C) 2013 Canonical Ltd.

 * Choice of algorithm:

 *  Copyright (C) 2018 WMWare Inc.

 *

 * This file contains the main data structure and API definitions.

 */

	struct lock_class_key mutex_key;

	const char *acquire_name;

	const char *mutex_name;

	unsigned int is_wait_die;

};

struct ww_acquire_ctx {

	struct task_struct *task;

	unsigned long stamp;

	unsigned int acquired;

	unsigned short wounded;

	unsigned short is_wait_die;

#ifdef CONFIG_DEBUG_MUTEXES

	unsigned int done_acquire;

	struct ww_class *ww_class;

# define __WW_CLASS_MUTEX_INITIALIZER(lockname, class)

#endif

#define __WW_CLASS_INITIALIZER(ww_class) \

#define __WW_CLASS_INITIALIZER(ww_class, _is_wait_die)	    \

		{ .stamp = ATOMIC_LONG_INIT(0) \

		, .acquire_name = #ww_class "_acquire" \

		, .mutex_name = #ww_class "_mutex" }

		, .mutex_name = #ww_class "_mutex" \

		, .is_wait_die = _is_wait_die }

#define __WW_MUTEX_INITIALIZER(lockname, class) \

		{ .base =  __MUTEX_INITIALIZER(lockname.base) \

		__WW_CLASS_MUTEX_INITIALIZER(lockname, class) }

#define DEFINE_WD_CLASS(classname) \

	struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 1)

#define DEFINE_WW_CLASS(classname) \

	struct ww_class classname = __WW_CLASS_INITIALIZER(classname)

	struct ww_class classname = __WW_CLASS_INITIALIZER(classname, 0)

#define DEFINE_WW_MUTEX(mutexname, ww_class) \

	struct ww_mutex mutexname = __WW_MUTEX_INITIALIZER(mutexname, ww_class)

	ctx->task = current;

	ctx->stamp = atomic_long_inc_return_relaxed(&ww_class->stamp);

	ctx->acquired = 0;

	ctx->wounded = false;

	ctx->is_wait_die = ww_class->is_wait_die;

#ifdef CONFIG_DEBUG_MUTEXES

	ctx->ww_class = ww_class;

	ctx->done_acquire = 0;

};

#include <linux/ww_mutex.h>

static DEFINE_WW_CLASS(torture_ww_class);

static DEFINE_WD_CLASS(torture_ww_class);

static DEFINE_WW_MUTEX(torture_ww_mutex_0, &torture_ww_class);

static DEFINE_WW_MUTEX(torture_ww_mutex_1, &torture_ww_class);

static DEFINE_WW_MUTEX(torture_ww_mutex_2, &torture_ww_class);