Searched full:might (Results 1 – 25 of 3777) sorted by relevance
12345678910>>...152
| /Linux-v5.4/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 | 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 …]
|
| /Linux-v5.4/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 …]
|
| /Linux-v5.4/Documentation/RCU/ |
| D | rcu_dereference.txt | 103 can now be speculated, such that it might happen before the
179 might provide, especially if you are making use of feedback-based
239 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
240 but you should not be. After all, the updater might have been invoked
305 first pointer might be. This lack of knowledge prevents the compiler
306 from carrying out optimizations that otherwise might destroy the ordering
310 But without rcu_dereference(), the compiler knows more than you might
371 2. If the access might be within an RCU read-side critical section
379 3. If the access might be within an RCU read-side critical section
398 is appropriate. In addition, rcu_dereference_raw() might be
[all …]
|
| 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
179 Quick Quiz #1: Is there any other situation where rcu_barrier() might
182 Your module might have additional complications. For example, if your
281 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,
104 Why might the rcu_dereference_sched() be necessary on Alpha, given
107 Answer: The caller to set_nmi_callback() might well have
111 just after the new handler was set might see the pointer
|
| D | stallwarn.txt | 25 really expected and desirable behavior, you might need to add
42 o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
49 memory, you might see stall-warning messages.
57 CONFIG_PREEMPT_RCU case, you might see stall-warning
204 last noted the beginning of a grace period, which might be the current
205 (stalled) grace period, or it might be some earlier grace period (for
206 example, if the CPU might have been in dyntick-idle mode for an extended
|
| /Linux-v5.4/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
|
| /Linux-v5.4/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
|
| /Linux-v5.4/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
|
| D | management-style.rst | 15 might not actually be true. You'll have to decide for yourself.
78 huge amounts of money that you might not be able to repay, the only
103 might be the wrong thing. You should always reserve the right to change
111 This preemptive admission of incompetence might also make the people who
173 might even be amused.
208 not necessarily translate to other areas. So you might prod people in
209 specific directions, but let's face it, they might be good at what they
|
| /Linux-v5.4/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.
|
| /Linux-v5.4/Documentation/media/uapi/rc/ |
| D | lirc-set-wideband-receiver.rst | 45 This might be useful of receivers that have otherwise narrow band receiver
46 that prevents them to be used with some remotes. Wide band receiver might
52 Wide band receiver might be implictly enabled if you enable
|
| /Linux-v5.4/Documentation/ |
| D | DMA-attributes.txt | 76 buffer from CPU domain to device domain. Some advanced use cases might
87 might be a time consuming operation, especially if the buffers are
111 pages). You might want to specify this if:
114 You might know that the accesses are likely to be sequential or
121 might be the case.
|
| /Linux-v5.4/arch/arm64/ |
| D | Kconfig | 325 …bool "Cortex-A53: 826319: System might deadlock if a write cannot complete until read data is acce…
347 …bool "Cortex-A53: 827319: Data cache clean instructions might cause overlapping transactions to th…
369 bool "Cortex-A53: 824069: Cache line might not be marked as clean after a CleanShared snoop"
380 address, then this erratum might cause a clean cache line to be
392 bool "Cortex-A53: 819472: Store exclusive instructions might cause data corruption"
402 maintenance operation to the same address, then this erratum might
420 Affected Cortex-A57 parts might deadlock when exclusive load/store
432 …bool "Cortex-A57: 834220: Stage 2 translation fault might be incorrectly reported in presence of a…
439 Affected Cortex-A57 parts might report a Stage 2 translation
453 bool "Cortex-A53: 845719: a load might read incorrect data"
[all …]
|
| /Linux-v5.4/drivers/media/usb/pvrusb2/ |
| D | pvrusb2.h | 12 might want to increase this - however the driver operation will not
14 won't have an ID assigned and it might not be possible to specify
|
| /Linux-v5.4/net/ax25/ |
| D | TODO | 6 A device might be deleted after lookup in the SIOCADDRT ioctl but before it's
9 Routes to a device being taken down might be deleted by ax25_rt_device_down
|
| /Linux-v5.4/Documentation/fb/ |
| D | vesafb.rst | 74 If this does not work, this might be because your BIOS does not support
76 Even if your board does, it might be the BIOS which does not. VESA BIOS
89 another (accelerated) X-Server like XF86_SVGA might or might not work.
107 * VBE 3.0 might work too. I have neither a gfx board with VBE 3.0
|
| /Linux-v5.4/arch/x86/ |
| D | Kconfig.cpu | 398 CPU might render the kernel unbootable.
412 CPU might render the kernel unbootable.
425 CPU might render the kernel unbootable.
439 CPU might render the kernel unbootable.
452 CPU might render the kernel unbootable.
466 CPU might render the kernel unbootable.
480 CPU might render the kernel unbootable.
493 CPU might render the kernel unbootable.
|
| /Linux-v5.4/Documentation/vm/ |
| D | frontswap.rst | 87 and size (such as with compression) or secretly moved (as might be
144 request (i.e. provides no memory despite claiming it might),
186 page, it could accept every ninth page, or it might accept every
243 choose to accept pages only until host-swapping might be imminent,
247 frontswap: Since any "store" might fail, there must always be a real
250 capability of holding every page that the swap device might have held
251 and the possibility that it might hold no pages at all. This means
|
| /Linux-v5.4/Documentation/driver-api/pm/ |
| D | devices.rst | 84 synergies exist, so that several drivers using runtime PM might put the system
244 For simple drivers, suspend might quiesce the device using class code
249 More power-aware drivers might prepare the devices for triggering system wakeup
405 vectors, like PCI, generally need it; otherwise a driver might encounter
420 might identify GPIO signals hooked up to a switch or other external hardware,
485 the end of resume might not be the one which preceded suspension.
592 Although in principle the image might be loaded into memory and the
666 Device low-power states aren't standard. One device might only handle
667 "on" and "off", while another might support a dozen different versions of
679 might be able to treat DMA completion as a wakeup event (sometimes DMA can stay
[all …]
|
| /Linux-v5.4/Documentation/x86/ |
| D | intel_mpx.rst | 47 when it calls the prctl(). This might be hard to guarantee if the app
50 Also be careful not to call out to any other code which might be
151 allocated which might contain pointers that might eventually need
156 way of controlling how all the parts of the app might allocate memory
251 However, if users did this, the kernel might be fooled in to unmapping an
|
| /Linux-v5.4/fs/ocfs2/cluster/ |
| D | quorum.c | 194 * the connection. the hold will be droped in conn_up or hb_down. it might be
195 * perpetuated by con_err until hb_down. if we already have a conn, we might
219 /* hb going down releases any holds we might have had due to this node from
244 * though we might be doing so after waiting for holds to drain. Here
262 * hb_up or hb_down. it might be perpetuated by con_err until hb_down. if
263 * it's already heartbeating we might be dropping a hold that conn_up got.
|
| /Linux-v5.4/Documentation/devicetree/bindings/sound/ |
| D | cs42l42.txt | 31 debounce, the tip sense pin might be noisy on a plug event.
43 With no debounce, the tip sense pin might be noisy on an unplug event.
76 hardware setups, a designer might want to tweak this. This is an array of
|
| /Linux-v5.4/Documentation/driver-api/gpio/ |
| D | legacy.rst | 34 value might be driven ... supporting "wire-OR" and similar schemes
69 One platform might implement it as simple inline functions accessing chip
70 registers; another might implement it by delegating through abstractions
121 example, a number might be valid but temporarily unused on a given board.
212 /* GPIO INPUT: return zero or nonzero, might sleep */
215 /* GPIO OUTPUT, might sleep */
223 Other than the fact that these accessors might sleep, and will work
447 A GPIO controller on a SOC might be tightly coupled with the pinctrl
489 this is highly chip-specific and nonportable. One platform might not need
490 explicit multiplexing; another might have just two options for use of any
[all …]
|
12345678910>>...152
