| /kernel/linux/linux-5.10/Documentation/livepatch/ |
| D | cumulative-patches.rst | 5 There might be dependencies between livepatches. If multiple patches need
10 This might become a maintenance nightmare. Especially when more patches
36 As a result, the livepatch authors might maintain sources only for one
42 actually in use. Also the livepatch might then be seen as a "normal"
83 As a result, it might be dangerous to replace newer cumulative patches by
84 older ones. The old livepatches might not provide the necessary callbacks.
86 This might be seen as a limitation in some scenarios. But it makes life
101 A good practice might be to remove shadow variables in the post-unpatch
|
| D | system-state.rst | 13 The problems might come with shadow variables and callbacks. They might
31 The state of the system might get modified either by several livepatch callbacks
99 It might be the original system state or the state modification
113 - Allocate *state->data* when necessary. The allocation might fail
125 - Clean up its own mess in case of error. It might be done by a custom
154 state. It might mean doing nothing.
166 It might be called also during the transition reverse. Therefore it
|
| D | livepatch.rst | 74 the same way to the rest of the system. In this case, the functions might
77 But there are more complex fixes. For example, a patch might change
79 might exchange meaning of some temporary structures and update
249 might want to access functions or data from the original source file
283 together. Note that patched modules might be loaded later than
284 the patch itself and the relevant functions might be patched
320 Second, the error code might be used to refuse loading the module when
349 Note that functions might be patched multiple times. The ftrace handler
357 functions might be patched two times only during the transition period.
363 All enabled patches might get replaced by a cumulative patch that
[all …]
|
| /kernel/linux/linux-4.19/Documentation/isdn/ |
| D | README.x25 | 6 As new versions appear, the stuff described here might suddenly change
12 have not been tested in a large scale. Therefore, you might encounter
17 might result in problems.
33 in the Linux source tree since version 2.1.16. The isdn subsystem might be
60 X.25 on top of isdn might be useful with two different scenarios:
62 - You might want to access a public X.25 data network from your Linux box.
80 - Or you might want to operate certain ISDN teleservices on your linux
127 called side used the DCE's lap_b address. Thus, l2_prot x75i might
172 use those for your first tests. Furthermore, you might check
177 The scripts distributed with the eftp4linux test releases might also
|
| D | README.concap | 11 This is currently only used inside the isdn subsystem. But it might
49 stick a header on the data. They also might need to set up or release
50 the WAN connection. They also might want to send other data for their
82 is provided) is outside our scope and might be different depending on
135 Protocols that don't process these primitives might fill in
204 /* the my_priv struct might contain a
216 The concept of the concap proto might help to reuse protocol code and
223 This might no longer hold for certain high speed WAN links (like
252 This might even allow for some protocol stacking. And the network
253 interface might even register the same data_req() function directly
|
| /kernel/linux/linux-5.10/net/netfilter/ |
| D | nf_conntrack_proto_dccp.c | 101 * We are the man in the middle. All the packets go through us but might
137 * sPO -> sIG Ignore, conntrack might be out of sync
138 * sOP -> sIG Ignore, conntrack might be out of sync
139 * sCR -> sIG Ignore, conntrack might be out of sync
140 * sCG -> sIG Ignore, conntrack might be out of sync
149 * sRQ -> sIG Ignore, might be response to ignored Request
150 * sRS -> sIG Ignore, might be response to ignored Request
151 * sPO -> sIG Ignore, might be response to ignored Request
152 * sOP -> sIG Ignore, might be response to ignored Request
153 * sCR -> sIG Ignore, might be response to ignored Request
[all …]
|
| /kernel/linux/linux-4.19/Documentation/ABI/stable/ |
| D | sysfs-hypervisor-xen | 7 Might return "<denied>" in case of special security settings
16 Might return "<denied>" in case of special security settings
25 Might return "<denied>" in case of special security settings
53 Might return "<denied>" in case of special security settings
70 Might return "0" in case of special security settings
102 Might return "<denied>" in case of special security settings
|
| /kernel/linux/linux-5.10/Documentation/ABI/stable/ |
| D | sysfs-hypervisor-xen | 7 Might return "<denied>" in case of special security settings
16 Might return "<denied>" in case of special security settings
25 Might return "<denied>" in case of special security settings
56 Might return "<denied>" in case of special security settings
73 Might return "0" in case of special security settings
105 Might return "<denied>" in case of special security settings
|
| /kernel/linux/linux-5.10/Documentation/RCU/ |
| D | rcu_dereference.rst | 106 can now be speculated, such that it might happen before the
182 might provide, especially if you are making use of feedback-based
243 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
244 but you should not be. After all, the updater might have been invoked
310 first pointer might be. This lack of knowledge prevents the compiler
311 from carrying out optimizations that otherwise might destroy the ordering
315 But without rcu_dereference(), the compiler knows more than you might
377 2. If the access might be within an RCU read-side critical section
385 3. If the access might be within an RCU read-side critical section
404 is appropriate. In addition, rcu_dereference_raw() might be
[all …]
|
| D | rcubarrier.rst | 19 such readers might hold a reference to them. RCU updates can therefore be
23 given that readers might well leave absolutely no trace of their
26 element p from a linked list might do the following, while holding an
38 context might then be as follows::
44 IRQ context. The function p_callback() might be defined as follows::
68 One might be tempted to try several back-to-back synchronize_rcu()
70 heavy RCU-callback load, then some of the callbacks might be deferred
187 Is there any other situation where rcu_barrier() might
192 Your module might have additional complications. For example, if your
302 Is there any other situation where rcu_barrier() might
|
| /kernel/linux/linux-4.19/Documentation/driver-api/soundwire/ |
| D | error_handling.rst | 21 and after a number of such errors are detected the bus might be reset. Note
38 backtracking and restarting the entire programming sequence might be a
39 solution. Alternatively some implementations might directly issue a bus
58 hard-reset might be the best solution.
62 that the Slave might behave in implementation-defined ways. The bus
|
| /kernel/linux/linux-5.10/Documentation/driver-api/soundwire/ |
| D | error_handling.rst | 21 and after a number of such errors are detected the bus might be reset. Note
38 backtracking and restarting the entire programming sequence might be a
39 solution. Alternatively some implementations might directly issue a bus
58 hard-reset might be the best solution.
62 that the Slave might behave in implementation-defined ways. The bus
|
| /kernel/linux/linux-4.19/net/netfilter/ |
| D | nf_conntrack_proto_dccp.c | 105 * We are the man in the middle. All the packets go through us but might
141 * sPO -> sIG Ignore, conntrack might be out of sync
142 * sOP -> sIG Ignore, conntrack might be out of sync
143 * sCR -> sIG Ignore, conntrack might be out of sync
144 * sCG -> sIG Ignore, conntrack might be out of sync
153 * sRQ -> sIG Ignore, might be response to ignored Request
154 * sRS -> sIG Ignore, might be response to ignored Request
155 * sPO -> sIG Ignore, might be response to ignored Request
156 * sOP -> sIG Ignore, might be response to ignored Request
157 * sCR -> sIG Ignore, might be response to ignored Request
[all …]
|
| /kernel/linux/linux-4.19/Documentation/livepatch/ |
| D | livepatch.txt | 74 the same way to the rest of the system. In this case, the functions might
77 But there are more complex fixes. For example, a patch might change
79 might exchange meaning of some temporary structures and update
250 might want to access functions or data from the original source file
284 together. Note that patched modules might be loaded later than
285 the patch itself and the relevant functions might be patched
330 Second, it might take some time until the entire system is migrated with
331 the hybrid consistency model being used. The patch revert might block
333 revert the patch using a separate operation that might be called
356 Registered patches might be enabled either by calling klp_enable_patch() or
[all …]
|
| /kernel/linux/linux-5.10/drivers/media/test-drivers/vidtv/ |
| D | vidtv_pes.h | 87 * @n_pes_h_s_bytes: Padding bytes. Might be used by an encoder if needed, gets
89 * @access_unit_len: The size of _one_ access unit (with any headers it might need)
104 /* might be used by an encoder if needed, gets discarded by decoder */
117 * @n_stuffing_bytes: Padding bytes. Might be used by an encoder if needed, gets
136 * @access_unit_len: The size of _one_ access unit (with any headers it might need)
148 * @n_pes_h_s_bytes: Padding bytes. Might be used by an encoder if needed, gets
|
| /kernel/linux/linux-4.19/Documentation/RCU/ |
| D | rcubarrier.txt | 16 such readers might hold a reference to them. RCU updates can therefore be
20 given that readers might well leave absolutely no trace of their
23 element p from a linked list might do the following, while holding an
35 context might then be as follows:
41 IRQ context. The function p_callback() might be defined as follows:
64 One might be tempted to try several back-to-back synchronize_rcu()
66 heavy RCU-callback load, then some of the callbacks might be deferred
180 Quick Quiz #1: Is there any other situation where rcu_barrier() might
183 Your module might have additional complications. For example, if your
282 Quick Quiz #1: Is there any other situation where rcu_barrier() might
|
| D | NMI-RCU.txt | 56 Quick Quiz: Why might the rcu_dereference_sched() be necessary on Alpha,
103 Why might the rcu_dereference_sched() be necessary on Alpha, given
106 Answer: The caller to set_nmi_callback() might well have
110 just after the new handler was set might see the pointer
|
| /kernel/linux/linux-4.19/Documentation/process/ |
| D | volatile-considered-harmful.rst | 36 change unexpectedly while the_lock is held. Any other code which might
40 compiler might think it knows what will be in shared_data, but the
61 Another situation where one might be tempted to use volatile is
76 - The above-mentioned accessor functions might use volatile on
92 - Pointers to data structures in coherent memory which might be modified
|
| /kernel/linux/linux-5.10/Documentation/process/ |
| D | volatile-considered-harmful.rst | 36 change unexpectedly while the_lock is held. Any other code which might
40 compiler might think it knows what will be in shared_data, but the
61 Another situation where one might be tempted to use volatile is
76 - The above-mentioned accessor functions might use volatile on
92 - Pointers to data structures in coherent memory which might be modified
|
| /kernel/linux/linux-4.19/Documentation/networking/ |
| D | ipv6.txt | 17 its functionality. This might be used when another module
39 on all interfaces. This might be used when one does not wish
59 This might be used when no IPv6 addresses are desired.
|
| /kernel/linux/linux-4.19/Documentation/media/uapi/rc/ |
| D | lirc-set-wideband-receiver.rst | 38 This might be useful of receivers that have otherwise narrow band receiver
39 that prevents them to be used with some remotes. Wide band receiver might
45 Wide band receiver might be implictly enabled if you enable
|
| /kernel/linux/linux-5.10/Documentation/userspace-api/media/rc/ |
| D | lirc-set-wideband-receiver.rst | 39 This might be useful of receivers that have otherwise narrow band receiver
40 that prevents them to be used with some remotes. Wide band receiver might
46 Wide band receiver might be implictly enabled if you enable
|
| /kernel/linux/linux-5.10/Documentation/networking/ |
| D | ipv6.rst | 23 its functionality. This might be used when another module
45 on all interfaces. This might be used when one does not wish
65 This might be used when no IPv6 addresses are desired.
|
| /kernel/linux/linux-5.10/Documentation/driver-api/media/drivers/ |
| D | bttv-devel.rst | 27 If your card isn't listed there, you might check the source code for
34 example. If your board has one, you might have to load a helper
37 you might want to check the video4linux mailing list archive first...
87 card installed, you might to check out if you can read these registers
91 You might also dig around in the ``*.ini`` files of the Windows applications.
|
| /kernel/linux/linux-5.10/Documentation/core-api/ |
| D | dma-attributes.rst | 50 buffer from CPU domain to device domain. Some advanced use cases might
61 might be a time consuming operation, especially if the buffers are
85 pages). You might want to specify this if:
88 You might know that the accesses are likely to be sequential or
95 might be the case.
|