€•¥Î      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ+/translations/zh_CN/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/zh_TW/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/it_IT/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/ja_JP/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/ko_KR/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/pt_BR/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ+/translations/sp_SP/locking/ww-mutex-design”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒ&Wound/Wait Deadlock-Proof Mutex Design”h]”hŒ&Wound/Wait Deadlock-Proof Mutex Design”…””}”(hh¼h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhh·h²hh³ŒE/var/lib/git/docbuild/linux/Documentation/locking/ww-mutex-design.rst”h´KubhŒ	paragraph”“”)”}”(hŒLPlease read mutex-design.rst first, as it applies to wait/wound mutexes too.”h]”hŒLPlease read mutex-design.rst first, as it applies to wait/wound mutexes too.”…””}”(hhÍh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khh·h²hubh¶)”}”(hhh]”(h»)”}”(hŒMotivation for WW-Mutexes”h]”hŒMotivation for WW-Mutexes”…””}”(hhÞh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhhÛh²hh³hÊh´KubhÌ)”}”(hXO  GPU's do operations that commonly involve many buffers.  Those buffers
can be shared across contexts/processes, exist in different memory
domains (for example VRAM vs system memory), and so on.  And with
PRIME / dmabuf, they can even be shared across devices.  So there are
a handful of situations where the driver needs to wait for buffers to
become ready.  If you think about this in terms of waiting on a buffer
mutex for it to become available, this presents a problem because
there is no way to guarantee that buffers appear in a execbuf/batch in
the same order in all contexts.  That is directly under control of
userspace, and a result of the sequence of GL calls that an application
makes.  Which results in the potential for deadlock.  The problem gets
more complex when you consider that the kernel may need to migrate the
buffer(s) into VRAM before the GPU operates on the buffer(s), which
may in turn require evicting some other buffers (and you don't want to
evict other buffers which are already queued up to the GPU), but for a
simplified understanding of the problem you can ignore this.”h]”hXS  GPUâ€™s do operations that commonly involve many buffers.  Those buffers
can be shared across contexts/processes, exist in different memory
domains (for example VRAM vs system memory), and so on.  And with
PRIME / dmabuf, they can even be shared across devices.  So there are
a handful of situations where the driver needs to wait for buffers to
become ready.  If you think about this in terms of waiting on a buffer
mutex for it to become available, this presents a problem because
there is no way to guarantee that buffers appear in a execbuf/batch in
the same order in all contexts.  That is directly under control of
userspace, and a result of the sequence of GL calls that an application
makes.  Which results in the potential for deadlock.  The problem gets
more complex when you consider that the kernel may need to migrate the
buffer(s) into VRAM before the GPU operates on the buffer(s), which
may in turn require evicting some other buffers (and you donâ€™t want to
evict other buffers which are already queued up to the GPU), but for a
simplified understanding of the problem you can ignore this.”…””}”(hhìh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K
hhÛh²hubhÌ)”}”(hX   The algorithm that the TTM graphics subsystem came up with for dealing with
this problem is quite simple.  For each group of buffers (execbuf) that need
to be locked, the caller would be assigned a unique reservation id/ticket,
from a global counter.  In case of deadlock while locking all the buffers
associated with a execbuf, the one with the lowest reservation ticket (i.e.
the oldest task) wins, and the one with the higher reservation id (i.e. the
younger task) unlocks all of the buffers that it has already locked, and then
tries again.”h]”hX   The algorithm that the TTM graphics subsystem came up with for dealing with
this problem is quite simple.  For each group of buffers (execbuf) that need
to be locked, the caller would be assigned a unique reservation id/ticket,
from a global counter.  In case of deadlock while locking all the buffers
associated with a execbuf, the one with the lowest reservation ticket (i.e.
the oldest task) wins, and the one with the higher reservation id (i.e. the
younger task) unlocks all of the buffers that it has already locked, and then
tries again.”…””}”(hhúh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhhÛh²hubhÌ)”}”(hX=  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 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.”h]”hX=  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 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.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K$hhÛh²hubeh}”(h]”Œmotivation-for-ww-mutexes”ah ]”h"]”Œmotivation for ww-mutexes”ah$]”h&]”uh1hµhh·h²hh³hÊh´Kubh¶)”}”(hhh]”(h»)”}”(hŒConcepts”h]”hŒConcepts”…””}”(hj!  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj  h²hh³hÊh´K:ubhÌ)”}”(hŒiCompared to normal mutexes two additional concepts/objects show up in the lock
interface for w/w mutexes:”h]”hŒiCompared to normal mutexes two additional concepts/objects show up in the lock
interface for w/w mutexes:”…””}”(hj/  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K<hj  h²hubhÌ)”}”(hX  Acquire context: To ensure eventual forward progress it is important that a task
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. An acquire context is representing a
transaction.”h]”hX’  Acquire context: To ensure eventual forward progress it is important that a task
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. An acquire context is representing a
transaction.”…””}”(hj=  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K?hj  h²hubhÌ)”}”(hŒâ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. The lock
class also specifies what algorithm to use, Wound-Wait or Wait-Die.”h]”hŒâ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. The lock
class also specifies what algorithm to use, Wound-Wait or Wait-Die.”…””}”(hjK  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KFhj  h²hubhÌ)”}”(hŒJFurthermore there are three different class of w/w lock acquire functions:”h]”hŒJFurthermore there are three different class of w/w lock acquire functions:”…””}”(hjY  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KJhj  h²hubhŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒ=Normal lock acquisition with a context, using ww_mutex_lock.
”h]”hÌ)”}”(hŒ<Normal lock acquisition with a context, using ww_mutex_lock.”h]”hŒ<Normal lock acquisition with a context, using ww_mutex_lock.”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KLhjn  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hji  h²hh³hÊh´Nubjm  )”}”(hX¿  Slowpath lock acquisition on the contending lock, used by the task that just
killed its transaction after having dropped all already acquired locks.
These functions have the _slow postfix.

From a simple semantics point-of-view the _slow functions are not strictly
required, since simply calling the normal ww_mutex_lock functions on the
contending lock (after having dropped all other already acquired locks) will
work correctly. After all if no other ww mutex has been acquired yet there's
no deadlock potential and hence the ww_mutex_lock call will block and not
prematurely return -EDEADLK. The advantage of the _slow functions is in
interface safety:

- ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
  has a void return type. Note that since ww mutex code needs loops/retries
  anyway the __must_check doesn't result in spurious warnings, even though the
  very first lock operation can never fail.
- When full debugging is enabled ww_mutex_lock_slow checks that all acquired
  ww mutex have been released (preventing deadlocks) and makes sure that we
  block on the contending lock (preventing spinning through the -EDEADLK
  slowpath until the contended lock can be acquired).
”h]”(hÌ)”}”(hŒ¼Slowpath lock acquisition on the contending lock, used by the task that just
killed its transaction after having dropped all already acquired locks.
These functions have the _slow postfix.”h]”hŒ¼Slowpath lock acquisition on the contending lock, used by the task that just
killed its transaction after having dropped all already acquired locks.
These functions have the _slow postfix.”…””}”(hjŠ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KNhj†  ubhÌ)”}”(hXÑ  From a simple semantics point-of-view the _slow functions are not strictly
required, since simply calling the normal ww_mutex_lock functions on the
contending lock (after having dropped all other already acquired locks) will
work correctly. After all if no other ww mutex has been acquired yet there's
no deadlock potential and hence the ww_mutex_lock call will block and not
prematurely return -EDEADLK. The advantage of the _slow functions is in
interface safety:”h]”hXÓ  From a simple semantics point-of-view the _slow functions are not strictly
required, since simply calling the normal ww_mutex_lock functions on the
contending lock (after having dropped all other already acquired locks) will
work correctly. After all if no other ww mutex has been acquired yet thereâ€™s
no deadlock potential and hence the ww_mutex_lock call will block and not
prematurely return -EDEADLK. The advantage of the _slow functions is in
interface safety:”…””}”(hj˜  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KRhj†  ubjh  )”}”(hhh]”(jm  )”}”(hX  ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
has a void return type. Note that since ww mutex code needs loops/retries
anyway the __must_check doesn't result in spurious warnings, even though the
very first lock operation can never fail.”h]”hÌ)”}”(hX  ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
has a void return type. Note that since ww mutex code needs loops/retries
anyway the __must_check doesn't result in spurious warnings, even though the
very first lock operation can never fail.”h]”hX  ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
has a void return type. Note that since ww mutex code needs loops/retries
anyway the __must_check doesnâ€™t result in spurious warnings, even though the
very first lock operation can never fail.”…””}”(hj­  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KZhj©  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj¦  ubjm  )”}”(hX  When full debugging is enabled ww_mutex_lock_slow checks that all acquired
ww mutex have been released (preventing deadlocks) and makes sure that we
block on the contending lock (preventing spinning through the -EDEADLK
slowpath until the contended lock can be acquired).
”h]”hÌ)”}”(hX  When full debugging is enabled ww_mutex_lock_slow checks that all acquired
ww mutex have been released (preventing deadlocks) and makes sure that we
block on the contending lock (preventing spinning through the -EDEADLK
slowpath until the contended lock can be acquired).”h]”hX  When full debugging is enabled ww_mutex_lock_slow checks that all acquired
ww mutex have been released (preventing deadlocks) and makes sure that we
block on the contending lock (preventing spinning through the -EDEADLK
slowpath until the contended lock can be acquired).”…””}”(hjÅ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K^hjÁ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj¦  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1jg  h³hÊh´KZhj†  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jl  hji  h²hh³Nh´Nubjm  )”}”(hXv  Functions to only acquire a single w/w mutex, which results in the exact same
semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL
context.

Again this is not strictly required. But often you only want to acquire a
single lock in which case it's pointless to set up an acquire context (and so
better to avoid grabbing a deadlock avoidance ticket).
”h]”(hÌ)”}”(hŒ¥Functions to only acquire a single w/w mutex, which results in the exact same
semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL
context.”h]”hŒ¥Functions to only acquire a single w/w mutex, which results in the exact same
semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL
context.”…””}”(hjë  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kchjç  ubhÌ)”}”(hŒÎAgain this is not strictly required. But often you only want to acquire a
single lock in which case it's pointless to set up an acquire context (and so
better to avoid grabbing a deadlock avoidance ticket).”h]”hŒÐAgain this is not strictly required. But often you only want to acquire a
single lock in which case itâ€™s pointless to set up an acquire context (and so
better to avoid grabbing a deadlock avoidance ticket).”…””}”(hjù  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kghjç  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jl  hji  h²hh³hÊh´Nubeh}”(h]”h ]”h"]”h$]”h&]”jß  Œ*”uh1jg  h³hÊh´KLhj  h²hubhÌ)”}”(hŒYOf course, all the usual variants for handling wake-ups due to signals are also
provided.”h]”hŒYOf course, all the usual variants for handling wake-ups due to signals are also
provided.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kkhj  h²hubeh}”(h]”Œconcepts”ah ]”h"]”Œconcepts”ah$]”h&]”uh1hµhh·h²hh³hÊh´K:ubh¶)”}”(hhh]”(h»)”}”(hŒUsage”h]”hŒUsage”…””}”(hj-  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj*  h²hh³hÊh´KoubhÌ)”}”(hX0  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.”h]”hX0  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.”…””}”(hj;  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kqhj*  h²hubhÌ)”}”(hŒkThree different ways to acquire locks within the same w/w class. Common
definitions for methods #1 and #2::”h]”hŒjThree different ways to acquire locks within the same w/w class. Common
definitions for methods #1 and #2:”…””}”(hjI  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kwhj*  h²hubhŒliteral_block”“”)”}”(hŒ®static DEFINE_WW_CLASS(ww_class);

struct obj {
      struct ww_mutex lock;
      /* obj data */
};

struct obj_entry {
      struct list_head head;
      struct obj *obj;
};”h]”hŒ®static DEFINE_WW_CLASS(ww_class);

struct obj {
      struct ww_mutex lock;
      /* obj data */
};

struct obj_entry {
      struct list_head head;
      struct obj *obj;
};”…””}”hjY  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1jW  h³hÊh´Kzhj*  h²hubhÌ)”}”(hXÓ  Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
This is useful if a list of required objects is already tracked somewhere.
Furthermore the lock helper can use propagate the -EALREADY return code back to
the caller as a signal that an object is twice on the list. This is useful if
the list is constructed from userspace input and the ABI requires userspace to
not have duplicate entries (e.g. for a gpu commandbuffer submission ioctl)::”h]”hXÔ  Method 1, using a list in execbuf->buffers thatâ€™s not allowed to be reordered.
This is useful if a list of required objects is already tracked somewhere.
Furthermore the lock helper can use propagate the -EALREADY return code back to
the caller as a signal that an object is twice on the list. This is useful if
the list is constructed from userspace input and the ABI requires userspace to
not have duplicate entries (e.g. for a gpu commandbuffer submission ioctl):”…””}”(hji  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K†hj*  h²hubjX  )”}”(hX`  int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj *res_obj = NULL;
      struct obj_entry *contended_entry = NULL;
      struct obj_entry *entry;

      ww_acquire_init(ctx, &ww_class);

retry:
      list_for_each_entry (entry, list, head) {
              if (entry->obj == res_obj) {
                      res_obj = NULL;
                      continue;
              }
              ret = ww_mutex_lock(&entry->obj->lock, ctx);
              if (ret < 0) {
                      contended_entry = entry;
                      goto err;
              }
      }

      ww_acquire_done(ctx);
      return 0;

err:
      list_for_each_entry_continue_reverse (entry, list, head)
              ww_mutex_unlock(&entry->obj->lock);

      if (res_obj)
              ww_mutex_unlock(&res_obj->lock);

      if (ret == -EDEADLK) {
              /* we lost out in a seqno race, lock and retry.. */
              ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
              res_obj = contended_entry->obj;
              goto retry;
      }
      ww_acquire_fini(ctx);

      return ret;
}”h]”hX`  int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj *res_obj = NULL;
      struct obj_entry *contended_entry = NULL;
      struct obj_entry *entry;

      ww_acquire_init(ctx, &ww_class);

retry:
      list_for_each_entry (entry, list, head) {
              if (entry->obj == res_obj) {
                      res_obj = NULL;
                      continue;
              }
              ret = ww_mutex_lock(&entry->obj->lock, ctx);
              if (ret < 0) {
                      contended_entry = entry;
                      goto err;
              }
      }

      ww_acquire_done(ctx);
      return 0;

err:
      list_for_each_entry_continue_reverse (entry, list, head)
              ww_mutex_unlock(&entry->obj->lock);

      if (res_obj)
              ww_mutex_unlock(&res_obj->lock);

      if (ret == -EDEADLK) {
              /* we lost out in a seqno race, lock and retry.. */
              ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
              res_obj = contended_entry->obj;
              goto retry;
      }
      ww_acquire_fini(ctx);

      return ret;
}”…””}”hjw  sbah}”(h]”h ]”h"]”h$]”h&]”jg  jh  uh1jW  h³hÊh´Khj*  h²hubhÌ)”}”(hŒÏMethod 2, using a list in execbuf->buffers that can be reordered. Same semantics
of duplicate entry detection using -EALREADY as method 1 above. But the
list-reordering allows for a bit more idiomatic code::”h]”hŒÎMethod 2, using a list in execbuf->buffers that can be reordered. Same semantics
of duplicate entry detection using -EALREADY as method 1 above. But the
list-reordering allows for a bit more idiomatic code:”…””}”(hj…  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K·hj*  h²hubjX  )”}”(hX  int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj_entry *entry, *entry2;

      ww_acquire_init(ctx, &ww_class);

      list_for_each_entry (entry, list, head) {
              ret = ww_mutex_lock(&entry->obj->lock, ctx);
              if (ret < 0) {
                      entry2 = entry;

                      list_for_each_entry_continue_reverse (entry2, list, head)
                              ww_mutex_unlock(&entry2->obj->lock);

                      if (ret != -EDEADLK) {
                              ww_acquire_fini(ctx);
                              return ret;
                      }

                      /* we lost out in a seqno race, lock and retry.. */
                      ww_mutex_lock_slow(&entry->obj->lock, ctx);

                      /*
                       * Move buf to head of the list, this will point
                       * buf->next to the first unlocked entry,
                       * restarting the for loop.
                       */
                      list_del(&entry->head);
                      list_add(&entry->head, list);
              }
      }

      ww_acquire_done(ctx);
      return 0;
}”h]”hX  int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj_entry *entry, *entry2;

      ww_acquire_init(ctx, &ww_class);

      list_for_each_entry (entry, list, head) {
              ret = ww_mutex_lock(&entry->obj->lock, ctx);
              if (ret < 0) {
                      entry2 = entry;

                      list_for_each_entry_continue_reverse (entry2, list, head)
                              ww_mutex_unlock(&entry2->obj->lock);

                      if (ret != -EDEADLK) {
                              ww_acquire_fini(ctx);
                              return ret;
                      }

                      /* we lost out in a seqno race, lock and retry.. */
                      ww_mutex_lock_slow(&entry->obj->lock, ctx);

                      /*
                       * Move buf to head of the list, this will point
                       * buf->next to the first unlocked entry,
                       * restarting the for loop.
                       */
                      list_del(&entry->head);
                      list_add(&entry->head, list);
              }
      }

      ww_acquire_done(ctx);
      return 0;
}”…””}”hj“  sbah}”(h]”h ]”h"]”h$]”h&]”jg  jh  uh1jW  h³hÊh´K»hj*  h²hubhÌ)”}”(hŒ9Unlocking works the same way for both methods #1 and #2::”h]”hŒ8Unlocking works the same way for both methods #1 and #2:”…””}”(hj¡  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kßhj*  h²hubjX  )”}”(hŒåvoid unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj_entry *entry;

      list_for_each_entry (entry, list, head)
              ww_mutex_unlock(&entry->obj->lock);

      ww_acquire_fini(ctx);
}”h]”hŒåvoid unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj_entry *entry;

      list_for_each_entry (entry, list, head)
              ww_mutex_unlock(&entry->obj->lock);

      ww_acquire_fini(ctx);
}”…””}”hj¯  sbah}”(h]”h ]”h"]”h$]”h&]”jg  jh  uh1jW  h³hÊh´Káhj*  h²hubhÌ)”}”(hX+  Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
e.g. when adjusting edges in a graph where each node has its own ww_mutex lock,
and edges can only be changed when holding the locks of all involved nodes. w/w
mutexes are a natural fit for such a case for two reasons:”h]”hX+  Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
e.g. when adjusting edges in a graph where each node has its own ww_mutex lock,
and edges can only be changed when holding the locks of all involved nodes. w/w
mutexes are a natural fit for such a case for two reasons:”…””}”(hj½  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Këhj*  h²hubjh  )”}”(hhh]”(jm  )”}”(hŒÊThey can handle lock-acquisition in any order which allows us to start walking
a graph from a starting point and then iteratively discovering new edges and
locking down the nodes those edges connect to.”h]”hÌ)”}”(hŒÊThey can handle lock-acquisition in any order which allows us to start walking
a graph from a starting point and then iteratively discovering new edges and
locking down the nodes those edges connect to.”h]”hŒÊThey can handle lock-acquisition in any order which allows us to start walking
a graph from a starting point and then iteratively discovering new edges and
locking down the nodes those edges connect to.”…””}”(hjÒ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KðhjÎ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjË  h²hh³hÊh´Nubjm  )”}”(hŒþDue to the -EALREADY return code signalling that a given objects is already
held there's no need for additional book-keeping to break cycles in the graph
or keep track off which looks are already held (when using more than one node
as a starting point).
”h]”hÌ)”}”(hŒýDue to the -EALREADY return code signalling that a given objects is already
held there's no need for additional book-keeping to break cycles in the graph
or keep track off which looks are already held (when using more than one node
as a starting point).”h]”hŒÿDue to the -EALREADY return code signalling that a given objects is already
held thereâ€™s no need for additional book-keeping to break cycles in the graph
or keep track off which looks are already held (when using more than one node
as a starting point).”…””}”(hjê  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kóhjæ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjË  h²hh³hÊh´Nubeh}”(h]”h ]”h"]”h$]”h&]”jß  jà  uh1jg  h³hÊh´Kðhj*  h²hubhÌ)”}”(hŒMNote that this approach differs in two important ways from the above methods:”h]”hŒMNote that this approach differs in two important ways from the above methods:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Køhj*  h²hubjh  )”}”(hhh]”(jm  )”}”(hX  Since the list of objects is dynamically constructed (and might very well be
different when retrying due to hitting the -EDEADLK die condition) there's
no need to keep any object on a persistent list when it's not locked. We can
therefore move the list_head into the object itself.”h]”hÌ)”}”(hX  Since the list of objects is dynamically constructed (and might very well be
different when retrying due to hitting the -EDEADLK die condition) there's
no need to keep any object on a persistent list when it's not locked. We can
therefore move the list_head into the object itself.”h]”hX  Since the list of objects is dynamically constructed (and might very well be
different when retrying due to hitting the -EDEADLK die condition) thereâ€™s
no need to keep any object on a persistent list when itâ€™s not locked. We can
therefore move the list_head into the object itself.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kúhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj  h²hh³hÊh´Nubjm  )”}”(hŒvOn the other hand the dynamic object list construction also means that the -EALREADY return
code can't be propagated.
”h]”hÌ)”}”(hŒuOn the other hand the dynamic object list construction also means that the -EALREADY return
code can't be propagated.”h]”hŒwOn the other hand the dynamic object list construction also means that the -EALREADY return
code canâ€™t be propagated.”…””}”(hj1  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kþhj-  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj  h²hh³hÊh´Nubeh}”(h]”h ]”h"]”h$]”h&]”jß  jà  uh1jg  h³hÊh´Kúhj*  h²hubhÌ)”}”(hXý  Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
list of starting nodes (passed in from userspace) using one of the above
methods. And then lock any additional objects affected by the operations using
method #3 below. The backoff/retry procedure will be a bit more involved, since
when the dynamic locking step hits -EDEADLK we also need to unlock all the
objects acquired with the fixed list. But the w/w mutex debug checks will catch
any interface misuse for these cases.”h]”hXý  Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
list of starting nodes (passed in from userspace) using one of the above
methods. And then lock any additional objects affected by the operations using
method #3 below. The backoff/retry procedure will be a bit more involved, since
when the dynamic locking step hits -EDEADLK we also need to unlock all the
objects acquired with the fixed list. But the w/w mutex debug checks will catch
any interface misuse for these cases.”…””}”(hjK  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj*  h²hubhÌ)”}”(hŒÙAlso, method 3 can't fail the lock acquisition step since it doesn't return
-EALREADY. Of course this would be different when using the _interruptible
variants, but that's outside of the scope of these examples here::”h]”hŒÞAlso, method 3 canâ€™t fail the lock acquisition step since it doesnâ€™t return
-EALREADY. Of course this would be different when using the _interruptible
variants, but thatâ€™s outside of the scope of these examples here:”…””}”(hjY  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M	hj*  h²hubjX  )”}”(hX  struct obj {
      struct ww_mutex ww_mutex;
      struct list_head locked_list;
};

static DEFINE_WW_CLASS(ww_class);

void __unlock_objs(struct list_head *list)
{
      struct obj *entry, *temp;

      list_for_each_entry_safe (entry, temp, list, locked_list) {
              /* need to do that before unlocking, since only the current lock holder is
              allowed to use object */
              list_del(&entry->locked_list);
              ww_mutex_unlock(entry->ww_mutex)
      }
}

void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj *obj;

      ww_acquire_init(ctx, &ww_class);

retry:
      /* re-init loop start state */
      loop {
              /* magic code which walks over a graph and decides which objects
               * to lock */

              ret = ww_mutex_lock(obj->ww_mutex, ctx);
              if (ret == -EALREADY) {
                      /* we have that one already, get to the next object */
                      continue;
              }
              if (ret == -EDEADLK) {
                      __unlock_objs(list);

                      ww_mutex_lock_slow(obj, ctx);
                      list_add(&entry->locked_list, list);
                      goto retry;
              }

              /* locked a new object, add it to the list */
              list_add_tail(&entry->locked_list, list);
      }

      ww_acquire_done(ctx);
      return 0;
}

void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      __unlock_objs(list);
      ww_acquire_fini(ctx);
}”h]”hX  struct obj {
      struct ww_mutex ww_mutex;
      struct list_head locked_list;
};

static DEFINE_WW_CLASS(ww_class);

void __unlock_objs(struct list_head *list)
{
      struct obj *entry, *temp;

      list_for_each_entry_safe (entry, temp, list, locked_list) {
              /* need to do that before unlocking, since only the current lock holder is
              allowed to use object */
              list_del(&entry->locked_list);
              ww_mutex_unlock(entry->ww_mutex)
      }
}

void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      struct obj *obj;

      ww_acquire_init(ctx, &ww_class);

retry:
      /* re-init loop start state */
      loop {
              /* magic code which walks over a graph and decides which objects
               * to lock */

              ret = ww_mutex_lock(obj->ww_mutex, ctx);
              if (ret == -EALREADY) {
                      /* we have that one already, get to the next object */
                      continue;
              }
              if (ret == -EDEADLK) {
                      __unlock_objs(list);

                      ww_mutex_lock_slow(obj, ctx);
                      list_add(&entry->locked_list, list);
                      goto retry;
              }

              /* locked a new object, add it to the list */
              list_add_tail(&entry->locked_list, list);
      }

      ww_acquire_done(ctx);
      return 0;
}

void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
{
      __unlock_objs(list);
      ww_acquire_fini(ctx);
}”…””}”hjg  sbah}”(h]”h ]”h"]”h$]”h&]”jg  jh  uh1jW  h³hÊh´Mhj*  h²hubhÌ)”}”(hX  Method 4: Only lock one single objects. In that case deadlock detection and
prevention is obviously overkill, since with grabbing just one lock you can't
produce a deadlock within just one class. To simplify this case the w/w mutex
api can be used with a NULL context.”h]”hX  Method 4: Only lock one single objects. In that case deadlock detection and
prevention is obviously overkill, since with grabbing just one lock you canâ€™t
produce a deadlock within just one class. To simplify this case the w/w mutex
api can be used with a NULL context.”…””}”(hju  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MGhj*  h²hubeh}”(h]”Œusage”ah ]”h"]”Œusage”ah$]”h&]”uh1hµhh·h²hh³hÊh´Koubh¶)”}”(hhh]”(h»)”}”(hŒImplementation Details”h]”hŒImplementation Details”…””}”(hjŽ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj‹  h²hh³hÊh´MMubh¶)”}”(hhh]”(h»)”}”(hŒDesign:”h]”hŒDesign:”…””}”(hjŸ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjœ  h²hh³hÊh´MPubhŒblock_quote”“”)”}”(hX™  ww_mutex currently encapsulates a struct mutex, this means no extra overhead for
normal mutex locks, which are far more common. As such there is only a small
increase in code size if wait/wound mutexes are not used.

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) 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, and optimization focus should
therefore be directed towards the uncontended cases.
”h]”(hÌ)”}”(hŒ×ww_mutex currently encapsulates a struct mutex, this means no extra overhead for
normal mutex locks, which are far more common. As such there is only a small
increase in code size if wait/wound mutexes are not used.”h]”hŒ×ww_mutex currently encapsulates a struct mutex, this means no extra overhead for
normal mutex locks, which are far more common. As such there is only a small
increase in code size if wait/wound mutexes are not used.”…””}”(hj³  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MRhj¯  ubhÌ)”}”(hŒ7We maintain the following invariants for the wait list:”h]”hŒ7We maintain the following invariants for the wait list:”…””}”(hjÁ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MVhj¯  ubhŒenumerated_list”“”)”}”(hhh]”(jm  )”}”(hŒ}Waiters with an acquire context are sorted by stamp order; waiters
without an acquire context are interspersed in FIFO order.”h]”hÌ)”}”(hŒ}Waiters with an acquire context are sorted by stamp order; waiters
without an acquire context are interspersed in FIFO order.”h]”hŒ}Waiters with an acquire context are sorted by stamp order; waiters
without an acquire context are interspersed in FIFO order.”…””}”(hjØ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MXhjÔ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjÑ  ubjm  )”}”(hŒÊ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.
”h]”hÌ)”}”(hŒÉ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.”h]”hŒÉ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.”…””}”(hjð  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MZhjì  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjÑ  ubeh}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œarabic”Œprefix”Œ(”Œsuffix”Œ)”uh1jÏ  hj¯  ubhÌ)”}”(hX]  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.”h]”hX]  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.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M^hj¯  ubhÌ)”}”(hŒÊIn general, not much contention is expected. The locks are typically used to
serialize access to resources for devices, and optimization focus should
therefore be directed towards the uncontended cases.”h]”hŒÊIn general, not much contention is expected. The locks are typically used to
serialize access to resources for devices, and optimization focus should
therefore be directed towards the uncontended cases.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhhj¯  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j­  h³hÊh´MRhjœ  h²hubeh}”(h]”Œdesign”ah ]”h"]”Œdesign:”ah$]”h&]”uh1hµhj‹  h²hh³hÊh´MPubh¶)”}”(hhh]”(h»)”}”(hŒLockdep:”h]”hŒLockdep:”…””}”(hj=  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj:  h²hh³hÊh´Mmubj®  )”}”(hX  Special care has been taken to warn for as many cases of api abuse
as possible. Some common api abuses will be caught with
CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended.

Some of the errors which will be warned about:
 - Forgetting to call ww_acquire_fini or ww_acquire_init.
 - Attempting to lock more mutexes after ww_acquire_done.
 - Attempting to lock the wrong mutex after -EDEADLK and
   unlocking all mutexes.
 - Attempting to lock the right mutex after -EDEADLK,
   before unlocking all mutexes.

 - Calling ww_mutex_lock_slow before -EDEADLK was returned.

 - Unlocking mutexes with the wrong unlock function.
 - Calling one of the ww_acquire_* twice on the same context.
 - Using a different ww_class for the mutex than for the ww_acquire_ctx.
 - Normal lockdep errors that can result in deadlocks.

Some of the lockdep errors that can result in deadlocks:
 - Calling ww_acquire_init to initialize a second ww_acquire_ctx before
   having called ww_acquire_fini on the first.
 - 'normal' deadlocks that can occur.
”h]”(hÌ)”}”(hŒ¹Special care has been taken to warn for as many cases of api abuse
as possible. Some common api abuses will be caught with
CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended.”h]”hŒ¹Special care has been taken to warn for as many cases of api abuse
as possible. Some common api abuses will be caught with
CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended.”…””}”(hjO  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MohjK  ubhŒdefinition_list”“”)”}”(hhh]”(hŒdefinition_list_item”“”)”}”(hXs  Some of the errors which will be warned about:
- Forgetting to call ww_acquire_fini or ww_acquire_init.
- Attempting to lock more mutexes after ww_acquire_done.
- Attempting to lock the wrong mutex after -EDEADLK and
  unlocking all mutexes.
- Attempting to lock the right mutex after -EDEADLK,
  before unlocking all mutexes.

- Calling ww_mutex_lock_slow before -EDEADLK was returned.

- Unlocking mutexes with the wrong unlock function.
- Calling one of the ww_acquire_* twice on the same context.
- Using a different ww_class for the mutex than for the ww_acquire_ctx.
- Normal lockdep errors that can result in deadlocks.
”h]”(hŒterm”“”)”}”(hŒ.Some of the errors which will be warned about:”h]”hŒ.Some of the errors which will be warned about:”…””}”(hjj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  h³hÊh´M€hjd  ubhŒ
definition”“”)”}”(hhh]”jh  )”}”(hhh]”(jm  )”}”(hŒ6Forgetting to call ww_acquire_fini or ww_acquire_init.”h]”hÌ)”}”(hj‚  h]”hŒ6Forgetting to call ww_acquire_fini or ww_acquire_init.”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mthj€  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒ6Attempting to lock more mutexes after ww_acquire_done.”h]”hÌ)”}”(hj™  h]”hŒ6Attempting to lock more mutexes after ww_acquire_done.”…””}”(hj›  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Muhj—  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒLAttempting to lock the wrong mutex after -EDEADLK and
unlocking all mutexes.”h]”hÌ)”}”(hŒLAttempting to lock the wrong mutex after -EDEADLK and
unlocking all mutexes.”h]”hŒLAttempting to lock the wrong mutex after -EDEADLK and
unlocking all mutexes.”…””}”(hj²  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mvhj®  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒQAttempting to lock the right mutex after -EDEADLK,
before unlocking all mutexes.
”h]”hÌ)”}”(hŒPAttempting to lock the right mutex after -EDEADLK,
before unlocking all mutexes.”h]”hŒPAttempting to lock the right mutex after -EDEADLK,
before unlocking all mutexes.”…””}”(hjÊ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MxhjÆ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒ9Calling ww_mutex_lock_slow before -EDEADLK was returned.
”h]”hÌ)”}”(hŒ8Calling ww_mutex_lock_slow before -EDEADLK was returned.”h]”hŒ8Calling ww_mutex_lock_slow before -EDEADLK was returned.”…””}”(hjâ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M{hjÞ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒ1Unlocking mutexes with the wrong unlock function.”h]”hÌ)”}”(hjø  h]”hŒ1Unlocking mutexes with the wrong unlock function.”…””}”(hjú  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M}hjö  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒ:Calling one of the ww_acquire_* twice on the same context.”h]”hÌ)”}”(hj  h]”hŒ:Calling one of the ww_acquire_* twice on the same context.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M~hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒEUsing a different ww_class for the mutex than for the ww_acquire_ctx.”h]”hÌ)”}”(hj&  h]”hŒEUsing a different ww_class for the mutex than for the ww_acquire_ctx.”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj$  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubjm  )”}”(hŒ4Normal lockdep errors that can result in deadlocks.
”h]”hÌ)”}”(hŒ3Normal lockdep errors that can result in deadlocks.”h]”hŒ3Normal lockdep errors that can result in deadlocks.”…””}”(hj?  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M€hj;  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hj}  ubeh}”(h]”h ]”h"]”h$]”h&]”jß  jà  uh1jg  h³hÊh´Mthjz  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jx  hjd  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jb  h³hÊh´M€hj_  ubjc  )”}”(hŒÓSome of the lockdep errors that can result in deadlocks:
- Calling ww_acquire_init to initialize a second ww_acquire_ctx before
  having called ww_acquire_fini on the first.
- 'normal' deadlocks that can occur.
”h]”(ji  )”}”(hŒ8Some of the lockdep errors that can result in deadlocks:”h]”hŒ8Some of the lockdep errors that can result in deadlocks:”…””}”(hji  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  h³hÊh´M…hje  ubjy  )”}”(hhh]”jh  )”}”(hhh]”(jm  )”}”(hŒpCalling ww_acquire_init to initialize a second ww_acquire_ctx before
having called ww_acquire_fini on the first.”h]”hÌ)”}”(hŒpCalling ww_acquire_init to initialize a second ww_acquire_ctx before
having called ww_acquire_fini on the first.”h]”hŒpCalling ww_acquire_init to initialize a second ww_acquire_ctx before
having called ww_acquire_fini on the first.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mƒhj}  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjz  ubjm  )”}”(hŒ#'normal' deadlocks that can occur.
”h]”hÌ)”}”(hŒ"'normal' deadlocks that can occur.”h]”hŒ&â€˜normalâ€™ deadlocks that can occur.”…””}”(hj™  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M…hj•  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jl  hjz  ubeh}”(h]”h ]”h"]”h$]”h&]”jß  jà  uh1jg  h³hÊh´Mƒhjw  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jx  hje  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jb  h³hÊh´M…hj_  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j]  hjK  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j­  h³hÊh´Mohj:  h²hubj^  )”}”(hhh]”jc  )”}”(hŒ\FIXME:
Update this section once we have the TASK_DEADLOCK task state flag magic
implemented.”h]”(ji  )”}”(hŒFIXME:”h]”hŒFIXME:”…””}”(hjÒ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  h³hÊh´MˆhjÎ  ubjy  )”}”(hhh]”hÌ)”}”(hŒUUpdate this section once we have the TASK_DEADLOCK task state flag magic
implemented.”h]”hŒUUpdate this section once we have the TASK_DEADLOCK task state flag magic
implemented.”…””}”(hjã  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mˆhjà  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jx  hjÎ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jb  h³hÊh´MˆhjË  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j]  hj:  h²hh³hÊh´Nubeh}”(h]”Œlockdep”ah ]”h"]”Œlockdep:”ah$]”h&]”uh1hµhj‹  h²hh³hÊh´Mmubeh}”(h]”Œimplementation-details”ah ]”h"]”Œimplementation details”ah$]”h&]”uh1hµhh·h²hh³hÊh´MMubeh}”(h]”Œ&wound-wait-deadlock-proof-mutex-design”ah ]”h"]”Œ&wound/wait deadlock-proof mutex design”ah$]”h&]”uh1hµhhh²hh³hÊh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÊuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hºNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j>  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÊŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(j  j  j  j  j'  j$  jˆ  j…  j  j  j7  j4  j  j  uŒ	nametypes”}”(j  ‰j  ‰j'  ‰jˆ  ‰j  ‰j7  ‰j  ‰uh}”(j  h·j  hÛj$  j  j…  j*  j  j‹  j4  jœ  j  j:  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.