Searched +full:lock +full:- +full:state (Results 1 – 25 of 168) sorted by relevance
1234567
| /Documentation/locking/ |
| D | locktypes.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 Lock types and their rules
15 - Sleeping locks
16 - CPU local locks
17 - Spinning locks
19 This document conceptually describes these lock types and provides rules
23 Lock categories
27 --------------
37 Sleeping lock types:
39 - mutex
[all …]
|
| D | rt-mutex.rst | 2 RT-mutex subsystem with PI support
5 RT-mutexes with priority inheritance are used to support PI-futexes,
7 (PTHREAD_PRIO_INHERIT). [See Documentation/locking/pi-futex.rst for more details
8 about PI-futexes.]
10 This technology was developed in the -rt tree and streamlined for
14 -----------------
16 RT-mutexes extend the semantics of simple mutexes by the priority
19 A low priority owner of a rt-mutex inherits the priority of a higher
20 priority waiter until the rt-mutex is released. If the temporarily
21 boosted owner blocks on a rt-mutex itself it propagates the priority
[all …]
|
| D | mutex-design.rst | 10 -----------------
24 --------------
28 (->owner) to keep track of the lock state during its lifetime. Field owner
29 actually contains `struct task_struct *` to the current lock owner and it is
31 to at least L1_CACHE_BYTES, low bits (3) are used to store extra state (e.g.,
32 if waiter list is non-empty). In its most basic form it also includes a
33 wait-queue and a spinlock that serializes access to it. Furthermore,
34 CONFIG_MUTEX_SPIN_ON_OWNER=y systems use a spinner MCS lock (->osq), described
38 taken, depending on the state of the lock:
40 (i) fastpath: tries to atomically acquire the lock by cmpxchg()ing the owner with
[all …]
|
| D | lockdep-design.rst | 8 Lock-class
9 ----------
15 tens of thousands of) instantiations. For example a lock in the inode
17 lock class.
19 The validator tracks the 'usage state' of lock-classes, and it tracks
20 the dependencies between different lock-classes. Lock usage indicates
21 how a lock is used with regard to its IRQ contexts, while lock
22 dependency can be understood as lock order, where L1 -> L2 suggests that
26 continuing effort to prove lock usages and dependencies are correct or
29 A lock-class's behavior is constructed by its instances collectively:
[all …]
|
| D | hwspinlock.rst | 12 For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP,
17 A generic hwspinlock framework allows platform-independent drivers to use
22 This is necessary, for example, for Inter-processor communications:
23 on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the
26 To achieve fast message-based communications, a minimal kernel support
35 A common hwspinlock interface makes it possible to have generic, platform-
47 API will usually want to communicate the lock's id to the remote core
67 Retrieve the global lock id for an OF phandle-based specific lock.
69 to get the global lock id of a specific hwspinlock, so that it can
72 The function returns a lock id number on success, -EPROBE_DEFER if
[all …]
|
| D | ww-mutex-design.rst | 2 Wound/Wait Deadlock-Proof Mutex Design
5 Please read mutex-design.rst first, as it applies to wait/wound mutexes too.
7 Motivation for WW-Mutexes
8 -------------------------
37 and the deadlock handling approach is called Wait-Die. The name is based on
39 If the transaction holding the lock is younger, the locking transaction waits.
40 If the transaction holding the lock is older, the locking transaction backs off
41 and dies. Hence Wait-Die.
42 There is also another algorithm called Wound-Wait:
43 If the transaction holding the lock is younger, the locking transaction
[all …]
|
| D | preempt-locking.rst | 2 Proper Locking Under a Preemptible Kernel: Keeping Kernel Code Preempt-Safe
21 RULE #1: Per-CPU data structures need explicit protection
32 First, since the data is per-CPU, it may not have explicit SMP locking, but
40 RULE #2: CPU state must be protected.
44 Under preemption, the state of the CPU must be protected. This is arch-
45 dependent, but includes CPU structures and state not preserved over a context
48 if the kernel is executing a floating-point instruction and is then preempted.
49 Remember, the kernel does not save FPU state except for user tasks. Therefore,
57 RULE #3: Lock acquire and release must be performed by same task
61 A lock acquired in one task must be released by the same task. This
[all …]
|
| D | robust-futexes.rst | 8 ----------
15 A futex is in essence a user-space address, e.g. a 32-bit lock variable
16 field. If userspace notices contention (the lock is already owned and
17 someone else wants to grab it too) then the lock is marked with a value
21 waiter with the waker - without them having to know about each other.
25 taken and released the lock, the futex is again back to 'uncontended'
26 state, and there's no in-kernel state associated with it. The kernel
30 "Robustness" is about dealing with crashes while holding a lock: if a
31 process exits prematurely while holding a pthread_mutex_t lock that is
33 pthread_mutex_t, or yum is kill -9-ed), then waiters for that lock need
[all …]
|
| D | pi-futex.rst | 2 Lightweight PI-futexes
7 - in the user-space fastpath a PI-enabled futex involves no kernel work
9 calls - just pure fast atomic ops in userspace.
11 - even in the slowpath, the system call and scheduling pattern is very
14 - the in-kernel PI implementation is streamlined around the mutex
16 relatively simple: only a single owner may own a lock (i.e. no
17 read-write lock support), only the owner may unlock a lock, no
20 Priority Inheritance - why?
21 ---------------------------
23 The short reply: user-space PI helps achieving/improving determinism for
[all …]
|
| D | lockstat.rst | 2 Lock Statistics
14 Because things like lock contention can severely impact performance.
19 Lockdep already has hooks in the lock functions and maps lock instances to
20 lock classes. We build on that (see Documentation/locking/lockdep-design.rst).
21 The graph below shows the relation between the lock functions and the various
26 lock _____
44 lock, unlock - the regular lock functions
45 __* - the hooks
46 <> - states
50 con-bounces
[all …]
|
| /Documentation/filesystems/nfs/ |
| D | client-identifier.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 instances in order to maintain file open and lock state during
19 ------------
21 The NFSv4 protocol uses "lease-based file locking". Leases help
22 NFSv4 servers provide file lock guarantees and manage their
26 The server collects each client's file open and lock state under
35 and lock state after a certain period of time. When a client
36 restarts, it indicates to servers that open and lock state
42 their state, the server uses this list to distinguish amongst
43 clients that held state before the server restarted and clients
[all …]
|
| /Documentation/netlink/specs/ |
| D | dpll.yaml | 1 # SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)
8 -
16 -
20 -
23 render-max: true
24 -
26 name: lock-status
28 provides information of dpll device lock status, valid values for
31 -
37 -
[all …]
|
| /Documentation/filesystems/ |
| D | gfs2-glocks.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 This documents the basic principles of the glock state machine
11 1. A spinlock (gl_lockref.lock) which protects the internal state such
13 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
15 thread takes this lock, it must then call run_queue (usually via the
19 The gl_holders list contains all the queued lock requests (not
25 There are three lock states that users of the glock layer can request,
27 to the following DLM lock modes:
30 Glock mode DLM lock mode
32 UN IV/NL Unlocked (no DLM lock associated with glock) or NL
[all …]
|
| /Documentation/core-api/irq/ |
| D | irqflags-tracing.rst | 2 IRQ-flags state tracing
7 The "irq-flags tracing" feature "traces" hardirq and softirq state, in
9 every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that
13 and CONFIG_PROVE_RW_LOCKING to be offered by the generic lock debugging
15 CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these
20 category, because lots of lowlevel assembly code deal with irq-flags
21 state changes. But an architecture can be irq-flags-tracing enabled in a
22 rather straightforward and risk-free manner.
25 code-organizational changes first:
27 - add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file
[all …]
|
| /Documentation/arch/s390/ |
| D | vfio-ap-locking.rst | 1 .. SPDX-License-Identifier: GPL-2.0
10 .. code-block:: c
16 The Matrix Devices Lock (drivers/s390/crypto/vfio_ap_private.h)
17 ---------------------------------------------------------------
19 .. code-block:: c
28 The Matrix Devices Lock (matrix_dev->mdevs_lock) is implemented as a global
29 mutex contained within the single object of struct ap_matrix_dev. This lock
31 (matrix_dev->mdev_list). This lock must be held while reading from, writing to
35 The KVM Lock (include/linux/kvm_host.h)
36 ---------------------------------------
[all …]
|
| /Documentation/RCU/ |
| D | listRCU.rst | 3 Using RCU to Protect Read-Mostly Linked Lists
6 One of the most common uses of RCU is protecting read-mostly linked lists
9 This document describes several list-based RCU use cases.
21 Example 1: Read-mostly list: Deferred Destruction
22 -------------------------------------------------
33 list_entry_rcu((p)->tasks.next, struct task_struct, tasks)
52 list_del_rcu(&p->tasks);
54 call_rcu(&p->rcu, delayed_put_task_struct);
57 When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)``
59 writer lock protection. The list_del_rcu() invocation removes
[all …]
|
| /Documentation/core-api/ |
| D | maple_tree.rst | 1 .. SPDX-License-Identifier: GPL-2.0+
13 The Maple Tree is a B-Tree data type which is optimized for storing
14 non-overlapping ranges, including ranges of size 1. The tree was designed to
17 entry in a cache-efficient manner. The tree can also be put into an RCU-safe
19 synchronize on a lock, which can be the default spinlock, or the user can set
20 the lock to an external lock of a different type.
24 use the normal API. An :ref:`maple-tree-advanced-api` exists for more complex
34 :ref:`maple-tree-advanced-api`, but are blocked by the normal API.
39 Pre-allocating of nodes is also supported using the
40 :ref:`maple-tree-advanced-api`. This is useful for users who must guarantee a
[all …]
|
| /Documentation/driver-api/driver-model/ |
| D | design-patterns.rst | 9 1. State Container
13 1. State Container
21 The most common way to achieve this is to use the state container design
25 spinlock_t lock; /* Example member */
35 return -ENOMEM;
36 spin_lock_init(&foo->lock);
41 called. This is our state container for this instance of the device driver.
43 state around to all functions that need access to the state and its members.
72 spinlock_t lock;
89 queue_work(foo->wq, &foo->offload);
[all …]
|
| /Documentation/bpf/ |
| D | graph_ds_impl.rst | 5 This document describes implementation details of new-style "graph" data
13 Note that the intent of this document is to describe the current state of
22 ------------
31 no longer relevant. With the introduction of kfuncs, kptrs, and the any-context
35 Two such data structures - linked_list and rbtree - have many verification
44 ------------
47 helper functions - either standard map API helpers like ``bpf_map_update_elem``
48 or map-specific helpers. The new-style graph data structures instead use kfuncs
57 -------
59 The new-style data structures are intrusive and are defined similarly to their
[all …]
|
| /Documentation/RCU/Design/Memory-Ordering/ |
| D | Tree-RCU-Memory-Ordering.rst | 2 A Tour Through TREE_RCU's Grace-Period Memory Ordering
13 grace-period memory ordering guarantee is provided.
18 RCU grace periods provide extremely strong memory-ordering guarantees
19 for non-idle non-offline code.
22 period that are within RCU read-side critical sections.
25 of that grace period that are within RCU read-side critical sections.
27 Note well that RCU-sched read-side critical sections include any region
30 an extremely small region of preemption-disabled code, one can think of
37 a linked RCU-protected data structure, and phase two frees that element.
38 For this to work, any readers that have witnessed state prior to the
[all …]
|
| /Documentation/translations/it_IT/locking/ |
| D | locktypes.rst | 1 .. SPDX-License-Identifier: GPL-2.0
3 .. include:: ../disclaimer-ita.rst
17 - blocchi ad attesa con sospensione
18 - blocchi locali per CPU
19 - blocchi ad attesa attiva
28 ---------------------------------
41 - mutex
42 - rt_mutex
43 - semaphore
44 - rw_semaphore
[all …]
|
| /Documentation/driver-api/serial/ |
| D | driver.rst | 10 The reference implementation is contained within amba-pl011.c.
15 --------------------------------
25 ---------------
38 -------
41 necessary locking using port->lock. There are some exceptions (which
44 There are two locks. A per-port spinlock, and an overall semaphore.
46 From the core driver perspective, the port->lock locks the following
49 port->mctrl
50 port->icount
51 port->state->xmit.head (circ_buf->head)
[all …]
|
| /Documentation/driver-api/surface_aggregator/ |
| D | internal.rst | 1 .. SPDX-License-Identifier: GPL-2.0+
54 internal-api
63 Lower-level packet transport is implemented in the *packet transport layer
68 packet payloads to higher-level layers.
71 around command-type packet payloads, i.e. requests (sent from host to EC),
90 Refer to Documentation/driver-api/surface_aggregator/client.rst for
93 that chapter and the Documentation/driver-api/surface_aggregator/ssh.rst
104 -------
131 The state of a packet is managed via its ``state`` flags
153 ------------
[all …]
|
| /Documentation/devicetree/bindings/iio/frequency/ |
| D | adi,adf4350.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Michael Hennerich <michael.hennerich@analog.com>
15 - adi,adf4350
16 - adi,adf4351
21 spi-max-frequency:
28 clock-names:
31 '#clock-cells':
34 clock-output-names:
[all …]
|
| /Documentation/filesystems/iomap/ |
| D | design.rst | 1 .. SPDX-License-Identifier: GPL-2.0
78 1. Obtain a space mapping via ``->iomap_begin``
80 2. For each sub-unit of work...
89 4. Release the mapping via ``->iomap_end``, if necessary
105 -----------
112 Processes hold this in shared mode to read file state and contents.
114 Processes often hold this in exclusive mode to change file state and
120 Processes wishing to insert folios must hold this lock in shared
122 Processes wishing to remove folios must hold this lock in exclusive
126 * ``dax_read_lock``: The RCU read lock that dax takes to prevent a
[all …]
|
1234567