| /openbmc/linux/Documentation/locking/ |
| H A D | mutex-design.rst | 9 What are mutexes?
12 In the Linux kernel, mutexes refer to a particular locking primitive
15 or similar theoretical text books. Mutexes are sleeping locks which
26 Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h
69 While formally kernel mutexes are sleepable locks, it is path (ii) that
87 - Held mutexes must not be reinitialized.
88 - Mutexes may not be used in hardware or software interrupt
95 - Uses symbolic names of mutexes, whenever they are printed
147 When to use mutexes
150 Unless the strict semantics of mutexes are unsuitable and/or the critical
|
| H A D | ww-mutex-design.rst | 5 Please read mutex-design.rst first, as it applies to wait/wound mutexes too.
7 Motivation for WW-Mutexes
60 Compared to normal mutexes two additional concepts/objects show up in the lock
61 interface for w/w mutexes:
70 W/w class: In contrast to normal mutexes the lock class needs to be explicit for
71 w/w mutexes, since it is required to initialize the acquire context. The lock
238 mutexes are a natural fit for such a case for two reasons:
340 increase in code size if wait/wound mutexes are not used.
373 - Attempting to lock more mutexes after ww_acquire_done.
375 unlocking all mutexes.
[all …]
|
| H A D | rt-mutex.rst | 5 RT-mutexes with priority inheritance are used to support PI-futexes,
16 RT-mutexes extend the semantics of simple mutexes by the priority
27 mutexes which protect shared resources. Priority inheritance is not a
40 RT-mutexes are optimized for fastpath operations and have no internal
|
| H A D | rt-mutex-design.rst | 120 - The highest priority process waiting on one of the mutexes
131 The PI chain is a list of processes and mutexes that may cause priority
139 Mutexes: L1, L2, L3, L4
177 have multiple chains merge at mutexes. If we add another process G that is
209 a tree of all top waiters of the mutexes that are owned by the process.
211 blocked on mutexes owned by the process.
229 the nesting of mutexes. Let's look at the example where we have 3 mutexes,
293 Now since mutexes can be defined by user-land applications, we don't want a DOS
294 type of application that nests large amounts of mutexes to create a large
318 mutexes short.
[all …]
|
| H A D | robust-futexes.rst | 42 There is a big conceptual problem with futex based mutexes though: it is
122 mechanism, which fully enables robust mutexes.
133 - no registration of individual locks is needed: robust mutexes don't
134 need any extra per-lock syscalls. Robust mutexes thus become a very
137 mutexes are just as fast.
158 [which it currently does for !pshared robust mutexes], and that took 256
|
| H A D | pi-futex.rst | 64 locks (such as futex-based pthread mutexes) is priority inheritance:
79 mutexes involves no kernel work at all - they behave quite similarly to
82 futexes.) Userspace uses atomic ops to lock/unlock these mutexes without
115 possible anyway, due to existing ABI properties of pthread mutexes.]
|
| H A D | locktypes.rst | 101 RT-mutexes are mutexes with support for priority inheritance (PI).
110 and rwlock_t to be implemented via RT-mutexes.
120 as mutexes and completions.
|
| /openbmc/linux/include/linux/ |
| H A D | ww_mutex.h | 3 * Wound/Wait Mutexes: blocking mutual exclusion locks with deadlock avoidance
113 * Initializes an context to acquire multiple mutexes of the given w/w class.
121 * for the same w/w class when acquiring mutexes can also result in undetected
183 * mutexes have been released with ww_mutex_unlock.
219 * In the die case the caller must release all currently held w/w mutexes for
222 * lock and proceed with trying to acquire further w/w mutexes (e.g. when
251 * In the die case the caller must release all currently held w/w mutexes for
254 * not acquire this lock and proceed with trying to acquire further w/w mutexes
277 * The caller must have released all w/w mutexes already acquired with the
280 * Afterwards the caller may continue to (re)acquire the other w/w mutexes it
[all …]
|
| H A D | mutex.h | 3 * Mutexes: blocking mutual exclusion locks
39 * Simple, straightforward mutexes with strict semantics:
49 * - held mutexes must not be reinitialized
50 * - mutexes may not be used in hardware or software interrupt
58 * - uses symbolic names of mutexes, whenever they are printed in debug output
|
| H A D | semaphore.h | 29 * Unlike mutexes, binary semaphores do not have an owner, so up() can
|
| /openbmc/linux/tools/perf/util/ |
| H A D | sharded_mutex.h | 11 * constantly hashed, a sharded mutex is an alternative global pool of mutexes
16 /* mutexes array is 1<<cap_bits in size. */
18 struct mutex mutexes[]; member
26 return &sm->mutexes[hash_bits(hash, sm->cap_bits)]; in sharded_mutex__get_mutex()
|
| H A D | sharded_mutex.c | 22 mutex_init(&result->mutexes[i]); in sharded_mutex__new()
30 mutex_destroy(&sm->mutexes[i]); in sharded_mutex__delete()
|
| /openbmc/linux/drivers/acpi/acpica/ |
| H A D | utmutex.c | 27 * DESCRIPTION: Create the system mutex objects. This includes mutexes,
90 * DESCRIPTION: Delete all of the system mutex objects. This includes mutexes,
206 * Deadlock prevention. Check if this thread owns any mutexes of value in acpi_ut_acquire_mutex()
301 * Deadlock prevention. Check if this thread owns any mutexes of value in acpi_ut_release_mutex()
|
| H A D | exmutex.c | 55 * This handles the case where several mutexes have been acquired in acpi_ex_unlink_mutex()
405 * This handles the case where several mutexes at the same level have been in acpi_ex_release_mutex()
451 * DESCRIPTION: Release all mutexes held by this thread
454 * Mutexes are not released when an individual control method is exited, but
468 /* Traverse the list of owned mutexes, releasing each one */ in acpi_ex_release_all_mutexes()
|
| /openbmc/qemu/tests/tsan/ |
| H A D | suppressions.tsan | 5 # TSan reports a double lock on RECURSIVE mutexes.
|
| /openbmc/linux/tools/testing/selftests/locking/ |
| H A D | ww_mutex.sh | 7 # Runs API tests for struct ww_mutex (Wait/Wound mutexes)
|
| /openbmc/linux/Documentation/devicetree/bindings/hwlock/ |
| H A D | qcom-hwspinlock.yaml | 13 The hardware block provides mutexes utilized between different processors on
|
| /openbmc/linux/lib/ |
| H A D | debug_locks.c | 6 * spinlocks, rwlocks, mutexes and rwsems.
|
| /openbmc/linux/kernel/locking/ |
| H A D | mutex.h | 3 * Mutexes: blocking mutual exclusion locks
|
| /openbmc/linux/kernel/configs/ |
| H A D | debug.config | 89 # Lock Debugging (spinlocks, mutexes, etc...)
|
| /openbmc/linux/rust/kernel/sync/ |
| H A D | lock.rs | 5 //! It contains a generic Rust lock and guard that allow for different backends (e.g., mutexes,
83 /// Some locks are known to be self-referential (e.g., mutexes), while others are architecture
|
| /openbmc/linux/fs/ocfs2/ |
| H A D | uptodate.h | 36 * be mutexes.
|
| /openbmc/openbmc/poky/meta/recipes-support/apr/apr/ |
| H A D | 0001-configure-Remove-runtime-test-for-mmap-that-can-map-.patch | 9 mutexes
|
| /openbmc/linux/drivers/gpu/drm/i915/gt/ |
| H A D | intel_engine_pm.h | 95 * the usual mutexes and relying on the engine-pm barrier in intel_engine_create_kernel_request()
|
| /openbmc/linux/include/uapi/xen/ |
| H A D | gntalloc.h | 56 * mutexes or close notification on communication channels.
|