Searched full:list (Results 1 – 25 of 1386) sorted by relevance
12345678910>>...56
| /Documentation/RCU/ |
| D | listRCU.rst | 7 (``struct list_head`` in list.h). One big advantage of this approach is
8 that all of the required memory ordering is provided by the list macros.
9 This document describes several list-based RCU use cases.
11 When iterating a list while holding the rcu_read_lock(), writers may
12 modify the list. The reader is guaranteed to see all of the elements
13 which were added to the list before they acquired the rcu_read_lock()
14 and are still on the list when they drop the rcu_read_unlock().
15 Elements which are added to, or removed from the list may or may not
21 Example 1: Read-mostly list: Deferred Destruction
25 all processes in the system. ``task_struct::tasks`` represents the list node that
[all …]
|
| D | rculist_nulls.rst | 4 Using RCU hlist_nulls to protect list and objects
19 Without 'nulls', a typical RCU linked list managing objects which are
88 "If the object is moved from one list to another list in-between the
90 object has moved to the end of a new list, the traversal will not
91 complete properly on the list it should have, since the object will
92 be on the end of the new list and there's not a way to tell it's on a
93 new list and restart the list traversal. I think that this can be
109 * Please note that new inserts are done at the head of list,
116 hlist_add_head_rcu(&obj->obj_node, list);
146 end-of-list marker for each slot of the hash table, we can detect
[all …]
|
| /Documentation/ABI/testing/ |
| D | debugfs-driver-dcc | 27 What: /sys/kernel/debug/dcc/.../[list-number]/config
37 manner; e.g. users can jump to list x only after
38 list y is configured and enabled. The input format for
45 echo R <addr> <n> <bus> >/sys/kernel/debug/dcc/../[list-number]/config
65 echo W <addr> <n> <bus type> > /sys/kernel/debug/dcc/../[list-number]/config
82 echo RW <addr> <n> <mask> > /sys/kernel/debug/dcc/../[list-number]/config
99 … echo L <loop count> <address count> <address>... > /sys/kernel/debug/dcc/../[list-number]/config
110 Space-separated list of addresses.
112 What: /sys/kernel/debug/dcc/.../[list-number]/enable
118 directory list number where users can enable/disable
[all …]
|
| D | sysfs-bus-event_source-devices-hv_24x7 | 3 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
28 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
38 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
45 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
52 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
59 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
66 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
73 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
80 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
91 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
| D | sysfs-firmware-papr-energy-scale-info | 3 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
13 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
18 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
23 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
28 Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
|
| D | sysfs-devices-system-cpu | 3 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
18 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
43 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
58 Contact: Linux memory management mailing list <linux-mm@kvack.org>
77 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
89 core_siblings_list: human-readable list of the logical CPU
99 thread_siblings_list: human-readable list of cpuX's hardware
115 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
125 available_governors: (RO) displays a space separated list of
148 Contact: Linux power management list <linux-pm@vger.kernel.org>
[all …]
|
| D | sysfs-devices-xenbus | 3 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
10 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
17 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
26 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
34 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
| D | sysfs-kernel-boot_params | 19 as a link list. In "setup_data" subdirectory there's one
20 subdirectory for each link list node named with the number
21 of the list nodes. The list node subdirectory contains two
|
| /Documentation/locking/ |
| D | robust-futex-ABI.rst | 12 linked list in user space, where it can be updated efficiently as locks
17 1) a one time call, per thread, to tell the kernel where its list of
24 call, and handles contested locking by maintaining a list of waiting
31 necessary list elements exactly as the kernel expects them. If it fails
53 setup that list.
56 pointer to a single linked list of 'lock entries', one per lock,
57 as described below. If the list is empty, the pointer will point
69 the address of the 'lock entry', during list insertion and removal,
73 Each 'lock entry' on the single linked list starting at 'head' consists
87 'lock entry' on this list, with its associated 'lock word' at the
[all …]
|
| D | ww-mutex-design.rst | 134 Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
135 This is useful if a list of required objects is already tracked somewhere.
137 the caller as a signal that an object is twice on the list. This is useful if
138 the list is constructed from userspace input and the ABI requires userspace to
141 int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
150 list_for_each_entry (entry, list, head) {
166 list_for_each_entry_continue_reverse (entry, list, head)
183 Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
185 list-reordering allows for a bit more idiomatic code::
187 int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
[all …]
|
| D | robust-futexes.rst | 89 At the heart of this new approach there is a per-thread private list of
91 userspace list is registered with the kernel via a new syscall [this
93 time, the kernel checks this user-space list: are there any robust futex
96 In the common case, at do_exit() time, there is no list registered, so
98 comparison. If the thread has registered a list, then normally the list
100 way then the list might be non-empty: in this case the kernel carefully
101 walks the list [not trusting it], and marks all locks that are owned by
105 The list is guaranteed to be private and per-thread at do_exit() time,
109 list is done after the futex is acquired by glibc, there is a few
114 before it could have added itself to the list. Glibc sets this
[all …]
|
| /Documentation/power/ |
| D | pm_qos_interface.rst | 20 A global list of CPU latency QoS requests is maintained along with an aggregated
22 to the request list or elements of the list. For CPU latency QoS, the
23 aggregated target value is simply the min of the request values held in the list
32 Will insert an element into the CPU latency QoS list with the target value.
33 Upon change to this list the new target is recomputed and any registered
39 Will update the list element pointed to by the handle with the new target
53 CPU latency QoS list.
93 Values are updated in response to changes of the request list.
96 simply the minimum of the request values held in the parameter list elements.
97 The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
[all …]
|
| /Documentation/gpu/ |
| D | drm-vm-bind-locking.rst | 37 a VM. The GEM object maintains a list of gpu_vm_bos, where each gpu_vm_bo
38 maintains a list of gpu_vmas.
50 gpu_vm or a GEM object. The dma_resv contains an array / list
81 gpu_vm's list of userptr gpu_vmas. With a CPU mm analogy this would
86 userptr gpu_vma on the gpu_vm's userptr list, and in write mode during mmu
96 * The ``gpu_vm->resv`` lock. Protects the gpu_vm's list of gpu_vmas needing
99 Furthermore, it typically protects the gpu_vm's list of evicted and
105 list of gpu_vm_bos. This is usually the same lock as the GEM
106 object's dma_resv, but some drivers protects this list differently,
108 * The ``gpu_vm list spinlocks``. With some implementations they are needed
[all …]
|
| /Documentation/process/ |
| D | embargoed-hardware-issues.rst | 35 is a private list of security officers who will help you coordinate a fix
38 The list is encrypted and email to the list can be sent by either PGP or
40 certificate. The list's PGP key and S/MIME certificate are available from
129 description of the problem and a list of any known affected silicon. If
136 mailing list which will be used for initial discussion with the reporter,
139 The hardware security team will provide the disclosing party a list of
153 The disclosing party should provide a list of contacts for all other
157 - The list of disclosed entities allows communication across the
172 team via the specific encrypted mailing-list.
181 The initial response team sets up an encrypted mailing-list or repurposes
[all …]
|
| /Documentation/infiniband/ |
| D | tag_matching.rst | 44 There are two types of matching objects used, the posted receive list and the
45 unexpected message list. The application posts receive buffers through calls
46 to the MPI receive routines in the posted receive list and posts send messages
47 using the MPI send routines. The head of the posted receive list may be
48 maintained by the hardware, with the software expected to shadow this list.
52 placed in the unexpected message list. Otherwise the match is processed,
58 the software unexpected message list for a matching receive. If a match is
62 list is maintained by the hardware, and there is space to add one more
63 pre-posted receive to this list, this receive is passed to the hardware.
64 Software is expected to shadow this list, to help with processing MPI cancel
[all …]
|
| /Documentation/driver-api/driver-model/ |
| D | binding.rst | 15 The bus type structure contains a list of all devices that are on that bus
17 inserted into the end of this list. The bus object also contains a
18 list of all drivers of that bus type. When driver_register is called
19 for a driver, it is inserted at the end of this list. These are the
26 When a new device is added, the bus's list of drivers is iterated over
57 driver's list of devices.
83 The bus's list of devices is iterated over to find a match. Devices
93 is removed from the driver's list of devices and the reference count
96 When a driver is removed, the list of devices that it supports is
98 one. The device is removed from that list and the symlinks removed.
|
| /Documentation/devicetree/bindings/mux/ |
| D | mux-consumer.yaml | 13 Mux controller consumers should specify a list of mux controllers that they
14 want to use with a property containing a 'mux-ctrl-list':
16 mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
24 each consumer. An optional property "mux-control-names" may contain a list of
30 "mux-state-names" can be used to provide a list of strings, to label
56 controller to an index into the list given by the "mux-controls" property.
62 controller to an index into the list given by the "mux-states"
|
| /Documentation/admin-guide/device-mapper/ |
| D | dm-dust.rst | 15 in the "bad block list" will fail with EIO ("Input/output error").
17 Writes of blocks in the "bad block list will result in the following:
19 1. Remove the block from the "bad block list".
102 These bad blocks will be stored in the "bad block list".
128 ...and writing to the bad blocks will remove the blocks from the list,
143 Attempting to add a bad block that already exists in the list will
150 Attempting to remove a bad block that doesn't exist in the list will
157 Counting the number of bad blocks in the bad block list
173 To find out if a specific block is in the bad block list, run the
178 The following message will print if the block is in the list::
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices-system-cpu | 69 Description: human-readable list of CPUs within the same core.
72 Values: decimal list.
80 Description: human-readable list of CPUs sharing the same physical_package_id.
83 Values: decimal list.
94 Description: human-readable list of CPUs within the same die.
96 Values: decimal list.
103 Description: human-readable list of CPUs within the same cluster.
105 Values: decimal list.
113 Description: human-readable list of cpuX's hardware threads within the same
116 Values: decimal list.
[all …]
|
| /Documentation/devicetree/bindings/pwm/ |
| D | pwm.txt | 7 PWM users should specify a list of PWM devices that they want to use
8 with a property containing a 'pwm-list':
10 pwm-list ::= <single-pwm> [pwm-list]
18 An optional property "pwm-names" may contain a list of strings to label
24 pwm_get() call to an index into the list given by the "pwms" property.
|
| /Documentation/mm/ |
| D | unevictable-lru.rst | 27 The Unevictable LRU facility adds an additional LRU list to track unevictable
41 The unevictable list addresses the following classes of unevictable pages:
55 The Unevictable LRU Folio List
58 The Unevictable LRU folio list is a lie. It was never an LRU-ordered
59 list, but a companion to the LRU-ordered anonymous and file, active and
60 inactive folio lists; and now it is not even a folio list. But following
62 imagine it as a fifth LRU folio list.
64 The Unevictable LRU infrastructure consists of an additional, per-node, LRU list
65 called the "unevictable" list and an associated folio flag, PG_unevictable, to
66 indicate that the folio is being managed on the unevictable list.
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | xlnx,audio-formatter.txt | 8 - interrupt-names: Names specified to list of interrupts in same
10 List of supported interrupt names are:
14 - interrupts: List of Interrupt numbers.
16 - clock-names: List of input clocks.
|
| /Documentation/filesystems/ |
| D | automount-support.rst | 47 (1) Create at least one list off which the vfsmounts to be expired can be
51 the mnt to the list using mnt_set_expiry()::
56 with a pointer to this list. This will process the list, marking every
70 If a mountpoint is moved, it gets removed from the expiration list. If a bind
72 expiration list and will not expire.
75 and the copies of those that are on an expiration list will be added to the
76 same expiration list.
|
| /Documentation/networking/devlink/ |
| D | mlxsw.rst | 13 .. list-table:: Generic parameters implemented
23 .. list-table:: Driver-specific parameters implemented
45 .. list-table:: devlink info versions implemented
66 .. list-table:: devlink info versions implemented
88 .. list-table:: List of Driver-specific Traps Registered by ``mlxsw``
|
| /Documentation/tools/rv/ |
| D | rv-list.rst | 4 rv-list
7 List available monitors
15 **rv list** [*OPTIONS*]
20 The **rv list** command prints all available monitors. These monitors
|
12345678910>>...56