| /kernel/linux/linux-6.6/Documentation/admin-guide/ |
| D | reporting-issues.rst | 21 In all other cases try your best guess which kernel part might be causing the
55 developers. It might be all that's needed for people already familiar with
89 kernel modules on-the-fly, which solutions like DKMS might be doing locally
93 that made the kernel set this flag might be causing the issue you face.
111 thoroughly for reports that might match your issue. If you find anything,
119 situations; during the merge window that actually might be even the best
149 link to it. Include or upload all other information that might be relevant,
188 the issue might have already been fixed there. If you first noticed the
212 might not get the issue solved in older releases: the fix might be too big
219 the issue in mainline, as its commit message might tell you if the fix is
[all …]
|
| D | quickly-build-trimmed-linux.rst | 18 which might be relevant for you.]*
32 # Hint: at this point you might want to adjust the build configuration; you'll
47 # Reminder: you might want to add or modify a build tag at this point.
73 that might occur at a particular point -- and how to then get things rolling
78 might want to switch to a rendered version, as it makes it a lot easier to
224 aspect in mind when using a kernel built with this make target, as it might
231 * Check if you might want to or have to adjust some kernel configuration
235 might need to decode a stack trace found for example in a 'panic', 'Oops',
296 version you care about, as git otherwise might retrieve the entire commit
307 At this point you might want to patch the sources again or set/modify a build
[all …]
|
| /kernel/linux/linux-6.6/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
|
| /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
|
| /kernel/linux/linux-6.6/net/netfilter/ |
| D | nf_conntrack_proto_dccp.c | 103 * We are the man in the middle. All the packets go through us but might
139 * sPO -> sIG Ignore, conntrack might be out of sync
140 * sOP -> sIG Ignore, conntrack might be out of sync
141 * sCR -> sIG Ignore, conntrack might be out of sync
142 * sCG -> sIG Ignore, conntrack might be out of sync
151 * sRQ -> sIG Ignore, might be response to ignored Request
152 * sRS -> sIG Ignore, might be response to ignored Request
153 * sPO -> sIG Ignore, might be response to ignored Request
154 * sOP -> sIG Ignore, might be response to ignored Request
155 * sCR -> sIG Ignore, might be response to ignored Request
[all …]
|
| /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-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-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-6.6/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-6.6/Documentation/RCU/ |
| D | rcu_dereference.rst | 113 can now be speculated, such that it might happen before the
195 might provide, especially if you are making use of feedback-based
260 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
261 but you should not be. After all, the updater might have been invoked
333 first pointer might be. This lack of knowledge prevents the compiler
334 from carrying out optimizations that otherwise might destroy the ordering
338 But without rcu_dereference(), the compiler knows more than you might
400 2. If the access might be within an RCU read-side critical section
408 3. If the access might be within an RCU read-side critical section
427 is appropriate. In addition, rcu_dereference_raw() might be
[all …]
|
| /kernel/linux/linux-6.6/Documentation/power/ |
| D | energy-model.rst | 17 Alternatively, userspace might be best positioned. And so on. In order to avoid
23 The power values might be expressed in micro-Watts or in an 'abstract scale'.
24 Multiple subsystems might use the EM and it is up to the system integrator to
28 powercap power values expressed in an 'abstract scale' might cause issues.
30 thus the real micro-Watts might be needed. An example of these requirements can
33 Kernel subsystems might implement automatic detection to check whether EM
110 subsystems which use EM might rely on this flag to check if all EM devices use
111 the same scale. If there are different scales, these subsystems might decide
123 (static + dynamic). These power values might be coming directly from
155 The EM which is registered using this method might not reflect correctly the
|
| /kernel/linux/linux-6.6/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/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-6.6/Documentation/core-api/ |
| D | printk-index.rst | 21 is not always trivial. Various changes might be backported. Various kernel
22 versions might be used on different monitored systems.
24 This is where the printk index feature might become useful. It provides
44 might appear in "vmlinux" when the module is built-in.
68 between various kernels. Especially the line number might change
118 interface might then show the printk formats including these prefixes.
|
| /kernel/linux/linux-6.6/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-6.6/Documentation/dev-tools/kunit/ |
| D | faq.rst | 34 (``tools/testing/kunit/kunit.py``) that might not support some architectures
37 In short, yes, you can run KUnit on other architectures, but it might require
55 usually just two or three. For example, someone might write an integration
62 code under test. For example, someone might write an end-to-end test for the
74 parameter. This might show details or error messages hidden by the kunit_tool
90 It also preserves any config changes you might make, so you can
|
| /kernel/linux/linux-6.6/tools/testing/selftests/mm/ |
| D | mkdirty.c | 3 * Test handling of code that might set PTE/PMD dirty in read-only VMAs.
107 * Unshare the page (populating a fresh anon page that might be set in test_ptrace_write()
178 /* Trigger page migration. Might not be available or fail. */ in test_page_migration()
202 * Write to the first page, which might populate a fresh anon THP in test_page_migration_thp()
217 /* Trigger page migration. Might not be available or fail. */ in test_page_migration_thp()
241 * Write to the first page, which might populate a fresh anon THP in test_pte_mapped_thp()
308 /* Place a page in a read-only VMA, which might set the PTE dirty. */ in test_uffdio_copy()
366 /* PTE-mapping a THP might propagate the dirty PMD bit to the PTEs. */ in main()
|
| /kernel/linux/linux-6.6/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-6.6/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 implicitly 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
|