Searched full:list (Results 1 – 25 of 1392) sorted by relevance
12345678910>>...56
| /Documentation/RCU/ |
| D | listRCU.rst | 7 ("struct list_head" in list.h). One big advantage of this approach
9 the list macros. This document describes several applications of RCU,
38 list_for_each_entry(e, &audit_tsklist, list) {
48 Here the list is searched under the lock, but the lock is dropped before
50 on, the list may well have been modified. This makes sense, since if
62 list_for_each_entry_rcu(e, &audit_tsklist, list) {
74 become list_for_each_entry_rcu(). The _rcu() list-traversal primitives
81 struct list_head *list)
86 list_for_each_entry(e, list, list) {
88 list_del(&e->list);
[all …]
|
| D | rculist_nulls.txt | 9 A typical RCU linked list managing objects which are
61 "If the object is moved from one list to another list in-between the
63 object has moved to the end of a new list, the traversal will not
64 complete properly on the list it should have, since the object will
65 be on the end of the new list and there's not a way to tell it's on a
66 new list and restart the list traversal. I think that this can be
80 * Please note that new inserts are done at the head of list,
92 hlist_add_head_rcu(&obj->obj_node, list);
116 end-of-list marker for each slot of the hash table, we can detect
123 scan the list again without harm.
[all …]
|
| /Documentation/ |
| D | robust-futex-ABI.txt | 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 | robust-futexes.txt | 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/scsi/ |
| D | hptiop.txt | 64 0x4000 Inbound List Base Address Low
65 0x4004 Inbound List Base Address High
66 0x4018 Inbound List Write Pointer
67 0x402C Inbound List Configuration and Control
68 0x4050 Outbound List Base Address Low
69 0x4054 Outbound List Base Address High
70 0x4058 Outbound List Copy Pointer Shadow Base Address Low
71 0x405C Outbound List Copy Pointer Shadow Base Address High
72 0x4088 Outbound List Interrupt Cause
73 0x408C Outbound List Interrupt Enable
[all …]
|
| /Documentation/power/ |
| D | pm_qos_interface.rst | 31 For each parameter a list of performance requests is maintained along with
33 changes to the request list or elements of the list. Typically the
35 in the parameter list elements.
43 Will insert an element into the list for that identified PM QoS class with the
44 target value. Upon change to this list the new target is recomputed and any
50 Will update the list element pointed to by the handle with the new target value
64 PM QoS class constraints list.
101 Values are updated in response to changes of the request list.
104 simply the minimum of the request values held in the parameter list elements.
105 The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
[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/process/ |
| D | embargoed-hardware-issues.rst | 33 is a private list of security officers who will help you to coordinate an
36 The list is encrypted and email to the list can be sent by either PGP or
38 certificate. The list's PGP key and S/MIME certificate are available from
124 a list of any known affected hardware. If your organization builds or
129 mailing-list which will be used for initial discussion with the reporter,
132 The hardware security team will provide the disclosing party a list of
146 The disclosing party should provide a list of contacts for all other
150 - The list of disclosed entities allows communication accross the
165 team via the specific encrypted mailing-list.
174 The initial response team sets up an encrypted mailing-list or repurposes
[all …]
|
| /Documentation/locking/ |
| 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 …]
|
| /Documentation/filesystems/nfs/ |
| D | fault_injection.txt | 20 <debug_dir>/nfsd. This will show a list of files that will be used for
35 The NFS server keeps a list of clients that have placed a mount call. If
36 this list is cleared, the server will have no knowledge of who the client
40 The NFS server keeps a list of what files are currently opened and who
41 they were opened by. Clearing this list will force the client to reopen
45 The NFS server keeps a list of what files are currently locked in the VFS.
46 Clearing this list will force the client to reclaim its locks (files are
47 unlocked through the VFS as they are cleared from this list).
51 has not changed since the delegation was awarded. Clearing this list will
|
| /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/ABI/testing/ |
| D | sysfs-bus-event_source-devices-hv_gpci | 3 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
12 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
19 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
26 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
33 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
40 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.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
|
| 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>
93 core_siblings_list: human-readable list of the logical CPU
103 thread_siblings_list: human-readable list of cpu#'s hardware
114 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
134 available_governors: (RO) displays a space separated list of
153 Contact: Linux power management list <linux-pm@vger.kernel.org>
[all …]
|
| D | sysfs-bus-event_source-devices-hv_24x7 | 3 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
13 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
20 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
27 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
38 Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices-node | 3 Contact: Linux Memory Management list <linux-mm@kvack.org>
9 Contact: Linux Memory Management list <linux-mm@kvack.org>
15 Contact: Linux Memory Management list <linux-mm@kvack.org>
21 Contact: Linux Memory Management list <linux-mm@kvack.org>
27 Contact: Linux Memory Management list <linux-mm@kvack.org>
34 Contact: Linux Memory Management list <linux-mm@kvack.org>
42 Contact: Linux Memory Management list <linux-mm@kvack.org>
48 Contact: Linux Memory Management list <linux-mm@kvack.org>
54 Contact: Linux Memory Management list <linux-mm@kvack.org>
61 Contact: Linux Memory Management list <linux-mm@kvack.org>
[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.
|
| D | imx-audmux.txt | 18 - fsl,port-config : List of configuration options for the specific port.
19 For imx31-audmux and above, it is a list of tuples
20 <ptcr pdcr>. For imx21-audmux it is a list of pcr
|
| /Documentation/vm/ |
| D | unevictable-lru.rst | 29 The Unevictable LRU facility adds an additional LRU list to track unevictable
43 The unevictable list addresses the following classes of unevictable pages:
55 The Unevictable Page List
58 The Unevictable LRU infrastructure consists of an additional, per-zone, LRU list
59 called the "unevictable" list and an associated page flag, PG_unevictable, to
60 indicate that the page is being managed on the unevictable list.
63 PG_active flag in that it indicates on which LRU list a page resides when
67 LRU list for a few reasons:
77 lists. If we were to maintain pages elsewhere than on an LRU-like list,
83 The unevictable list does not differentiate between file-backed and anonymous,
[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/filesystems/ |
| D | automount-support.txt | 42 (1) Create at least one list off which the vfsmounts to be expired can be
46 the mnt to the list using mnt_set_expiry()
50 with a pointer to this list. This will process the list, marking every
64 If a mountpoint is moved, it gets removed from the expiration list. If a bind
66 expiration list and will not expire.
69 and the copies of those that are on an expiration list will be added to the
70 same expiration list.
|
| /Documentation/devicetree/bindings/ufs/ |
| D | cdns,ufshc.txt | 5 Please see the ufshcd-pltfrm.txt for a list of all available properties.
8 - compatible : Compatible list, contains one of the following controllers:
18 - clocks : List of phandle and clock specifier pairs.
19 - clock-names : List of clock input name strings sorted in the same
|
| /Documentation/admin-guide/device-mapper/ |
| D | dm-dust.txt | 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".
88 These bad blocks will be stored in the "bad block list".
114 ...and writing to the bad blocks will remove the blocks from the list,
129 Attempting to add a bad block that already exists in the list will
136 Attempting to remove a bad block that doesn't exist in the list will
143 Counting the number of bad blocks in the bad block list:
159 To find out if a specific block is in the bad block list, run the
164 The following message will print if the block is in the list:
[all …]
|
| /Documentation/devicetree/bindings/clock/ |
| D | mvebu-core-clock.txt | 7 The following is a list of provided IDs and clock names on Armada 370/XP:
14 The following is a list of provided IDs and clock names on Armada 375:
20 The following is a list of provided IDs and clock names on Armada 380/385:
26 The following is a list of provided IDs and clock names on Armada 39x:
34 The following is a list of provided IDs and clock names on 98dx3236:
40 The following is a list of provided IDs and clock names on Kirkwood and Dove:
46 The following is a list of provided IDs and clock names on Orion5x:
|
| /Documentation/devicetree/bindings/power/reset/ |
| D | keystone-reset.txt | 29 - ti,wdt-list: WDT list that can cause SoC reset. It's not related
31 reset that's triggered by one of WDTs. The list is
54 ti,wdt-list = <0>;
65 ti,wdt-list = <0>, <2>;
|
12345678910>>...56