Searched full:held (Results 1 – 25 of 170) sorted by relevance
1234567
| /Documentation/ABI/testing/ |
| D | sysfs-bus-coresight-devices-etb10 | 33 Description: (Read) Shows the value held by the ETB status register. The value
40 Description: (Read) Shows the value held by the ETB RAM Read Pointer register
49 Description: (Read) Shows the value held by the ETB RAM Write Pointer register
65 Description: (Read) Shows the value held by the ETB Control register. The value
72 Description: (Read) Shows the value held by the ETB Formatter and Flush Status
80 Description: (Read) Shows the value held by the ETB Formatter and Flush Control
|
| D | sysfs-bus-coresight-devices-tmc | 21 Description: (Read) Shows the value held by the TMC status register. The value
28 Description: (Read) Shows the value held by the TMC RAM Read Pointer register
37 Description: (Read) Shows the value held by the TMC RAM Write Pointer register
53 Description: (Read) Shows the value held by the TMC Control register. The value
60 Description: (Read) Shows the value held by the TMC Formatter and Flush Status
68 Description: (Read) Shows the value held by the TMC Formatter and Flush Control
76 Description: (Read) Shows the value held by the TMC Mode register, which
|
| D | sysfs-driver-hid-prodikeys | 16 note held by the pc-midi driver.
|
| /Documentation/locking/ |
| D | robust-futex-ABI.rst | 9 futexes, for kernel assist of cleanup of held locks on task exit.
18 held robust_futexes begins, and
19 2) internal kernel code at exit, to handle any listed locks held
85 For each futex lock currently held by a thread, if it wants this
114 up locks held at the time of (a perhaps unexpectedly) exit.
121 still held by the departing thread, as described below.
125 lock structures for locks currently held by that thread should be on
128 A given futex lock structure in a user shared memory region may be held
133 When adding or removing a lock from its list of held locks, in order for
|
| D | lockdep-design.rst | 46 - 'ever held in STATE context'
47 - 'ever held as readlock in STATE context'
48 - 'ever held with STATE enabled'
49 - 'ever held as readlock with STATE enabled'
170 any rule violation between the new lock and any of the held locks.
238 must be held: lockdep_assert_held*(&lock) and lockdep_*pin_lock(&lock).
241 particular lock is held at a certain time (and generate a WARN() otherwise).
329 held locks is maintained, and a lightweight 64-bit hash value is
523 , which means lockdep has seen L1 held before L2 held in the same context at runtime.
524 And in deadlock detection, we care whether we could get blocked on L2 with L1 held,
[all …]
|
| D | rt-mutex.rst | 58 taskpointer 0 lock is held (fast release possible)
59 taskpointer 1 lock is held and has waiters [2]_
66 with ->wait_lock is held. To prevent any fast path cmpxchg to the lock,
|
| D | mutex-design.rst | 85 - A task may not exit with a mutex held.
86 - Memory areas where held locks reside must not be freed.
87 - Held mutexes must not be reinitialized.
98 list of all locks held in the system, printout of them.
|
| D | robust-futexes.rst | 46 then the kernel has no information to clean up after the held lock!
152 million (!) held locks, using the new method [on a 2GHz CPU]:
162 (1 million held locks are unheard of - we expect at most a handful of
163 locks to be held at a time. Nevertheless it's nice to know that this
191 If a futex is found to be held at exit time, the kernel sets the
|
| /Documentation/dev-tools/ |
| D | sparse.rst | 61 locking. These annotations tell sparse when a lock is held, with
64 __must_hold - The specified lock is held on function entry and exit.
66 __acquires - The specified lock is held on function exit, but not entry.
68 __releases - The specified lock is held on function entry, but not exit.
70 If the function enters and exits without the lock held, acquiring and
|
| /Documentation/arch/s390/ |
| D | vfio-ap-locking.rst | 31 (matrix_dev->mdev_list). This lock must be held while reading from, writing to
47 lock must be held by the vfio_ap device driver while one or more AP adapters,
69 KVM guest. This lock must be held:
91 held in order to access the KVM pointer since it is set and cleared under the
95 resources, so only the matrix_dev->mdevs_lock needs to be held.
114 held in write mode when pqap_hook value is set, and in read mode when the
|
| /Documentation/devicetree/bindings/remoteproc/ |
| D | qcom,wcnss-pil.yaml | 61 PX regulator to be held on behalf of the booting of the WCNSS core
65 MX regulator to be held on behalf of the booting of the WCNSS core.
69 CX regulator to be held on behalf of the booting of the WCNSS core.
129 Reference to the regulator to be held on behalf of the booting WCNSS
134 Reference to the regulator to be held on behalf of the booting WCNSS
139 Reference to the regulator to be held on behalf of the booting WCNSS
144 Reference to the regulator to be held on behalf of the booting WCNSS
|
| /Documentation/filesystems/nfs/ |
| D | pnfs.rst | 22 LAYOUTCOMMIT), and for each lseg held within.
33 layout driver type. The device ids are held in a RCU cache (struct
35 mount. The entries (struct nfs4_deviceid) themselves are held across
51 level cache. Its reference is held over the lifetime of the deviceid
|
| /Documentation/gpu/ |
| D | drm-vm-bind-locking.rst | 51 of dma_fences and a lock that needs to be held when adding
93 sleeping if the write side is held.
94 The write side is held by the core mm while calling mmu interval
131 held in relevant situations and also provides a means of making itself
173 // dma_resv to be held (it protects the gpu_vm_bo's list of
175 // dma_resv, it is already held at this point.
255 gpu_vms the object is bound to are typically not held. Only
256 the object's private dma_resv can be guaranteed to be held. If there
263 both the gpu_vm's dma_resv and the object's dma_resv is held, and the
323 Accessing the gpu_vm's lists without the dma_resv lock held
[all …]
|
| /Documentation/pcmcia/ |
| D | locking.rst | 26 be called with "skt_mutex" held::
43 be called with "ops_mutex" held::
52 called with "ops_mutex" held.
|
| /Documentation/leds/ |
| D | ledtrig-transient.rst | 12 features that require an on or off state to be held just once and then stay in
75 - state allows user to specify a transient state to be held for the specified
96 - transient state to be held. It has two values 0 or 1. 0 maps
98 held for the duration of the one shot timer and then the
128 held for the specified duration.
130 held for the specified duration.
|
| /Documentation/admin-guide/device-mapper/ |
| D | era.rst | 56 <current era> <held metadata root | '-'>
64 held metadata root The location, in blocks, of the metadata root
65 that has been 'held' for userspace read
66 access. '-' indicates there is no held root
|
| /Documentation/networking/devlink/ |
| D | index.rst | 15 the devlink instance lock is already held. Drivers can take the instance
16 lock by calling ``devl_lock()``. It is also held all callbacks of devlink
|
| /Documentation/RCU/ |
| D | lockdep.rst | 84 2. with files->file_lock held, or
100 one of these two cases held. Because rcu_dereference_protected() omits
114 either within an RCU read-side critical section or with wq->mutex held.
|
| D | lockdep-splat.rst | 31 3 locks held by scsi_scan_6/1552:
85 or with the ->queue_lock held. In particular, this would have suppressed
86 the above lockdep-RCU splat because ->queue_lock is held (see #2 in the
|
| D | UP.rst | 74 2. In some cases, the lock will be held across some kernel API,
78 with no locks held than to have to modify such APIs to allow
103 from a known environment in which no locks are held.
|
| /Documentation/devicetree/bindings/fpga/ |
| D | lattice-ice40-fpga-mgr.txt | 9 that unless the GPIO is held low during startup, the
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | cgroups.rst | 437 has processes attached, or is held alive by other subsystem-specific
551 (cgroup_mutex held by caller)
566 (cgroup_mutex held by caller)
576 (cgroup_mutex held by caller)
586 (cgroup_mutex held by caller)
595 (cgroup_mutex held by caller)
616 (cgroup_mutex held by caller)
630 (cgroup_mutex held by caller)
639 (cgroup_mutex held by caller)
658 (cgroup_mutex held by caller)
|
| /Documentation/networking/ |
| D | netdevices.rst | 28 held: register_netdev(), unregister_netdev().
29 Second group can be used when ``rtnl_lock`` is already held:
36 in context where ``rtnl_lock`` is not held (e.g. driver probe and remove paths).
155 ``rtnl_lock`` held.
|
| /Documentation/filesystems/ |
| D | directory-locking.rst | 161 lower than that of an already held lock.
165 held by the next thread in the cycle.
177 T1 is blocked on D1 which is held by T2
179 T2 is blocked on D2 which is held by T3
183 Tn is blocked on Dn which is held by T1.
|
| D | porting.rst | 252 * the child's ->d_lock is held
289 ->statfs() is now called without BKL held. BKL should have been
342 inode->i_lock held and it returns true if filesystems wants the inode to be
484 You must also keep in mind that ->fsync() is not called with i_mutex held
553 called with both ->i_lock and inode_hash_lock held; the former is *not*
555 of the in-tree instances did). inode_hash_lock is still held,
783 so the caller needs to drop the inode reference it held.
948 mmap_lock held. All in-tree users have been audited and do not seem to
949 depend on the mmap_lock being held, but out of tree users should verify
951 be called with the mmap_lock held.
[all …]
|
1234567