commit 50dbd96e4f31e28fc2fcc80abaabab4fb277227c · tjh.dev/kernel

+4 -4

Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst

··· 473 the bottom of the diagram above). 474 475 Plumbing this into the full grace-period execution is described 476 - `below <#Forcing%20Quiescent%20States>`__. 477 478 CPU-Hotplug Interface 479 ^^^^^^^^^^^^^^^^^^^^^ ··· 494 grace period. 495 496 Plumbing this into the full grace-period execution is described 497 - `below <#Forcing%20Quiescent%20States>`__. 498 499 Forcing Quiescent States 500 ^^^^^^^^^^^^^^^^^^^^^^^^ ··· 532 | RCU. But this diagram is complex enough as it is, so simplicity | 533 | overrode accuracy. You can think of it as poetic license, or you can | 534 | think of it as misdirection that is resolved in the | 535 - | `stitched-together diagram <#Putting%20It%20All%20Together>`__. | 536 +-----------------------------------------------------------------------+ 537 538 Grace-Period Cleanup ··· 596 that runs on some other CPU, proper ordering must in place in both the 597 callback function and the task being awakened. To see why this is 598 important, consider the top half of the `grace-period 599 - cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be 600 running on a CPU corresponding to the leftmost leaf ``rcu_node`` 601 structure, and awaken a task that is to run on a CPU corresponding to 602 the rightmost leaf ``rcu_node`` structure, and the grace-period kernel

··· 473 the bottom of the diagram above). 474 475 Plumbing this into the full grace-period execution is described 476 + `below <Forcing Quiescent States_>`__. 477 478 CPU-Hotplug Interface 479 ^^^^^^^^^^^^^^^^^^^^^ ··· 494 grace period. 495 496 Plumbing this into the full grace-period execution is described 497 + `below <Forcing Quiescent States_>`__. 498 499 Forcing Quiescent States 500 ^^^^^^^^^^^^^^^^^^^^^^^^ ··· 532 | RCU. But this diagram is complex enough as it is, so simplicity | 533 | overrode accuracy. You can think of it as poetic license, or you can | 534 | think of it as misdirection that is resolved in the | 535 + | `stitched-together diagram <Putting It All Together_>`__. | 536 +-----------------------------------------------------------------------+ 537 538 Grace-Period Cleanup ··· 596 that runs on some other CPU, proper ordering must in place in both the 597 callback function and the task being awakened. To see why this is 598 important, consider the top half of the `grace-period 599 + cleanup`_ diagram. The callback might be 600 running on a CPU corresponding to the leftmost leaf ``rcu_node`` 601 structure, and awaken a task that is to run on a CPU corresponding to 602 the rightmost leaf ``rcu_node`` structure, and the grace-period kernel

+10 -10

Documentation/RCU/Design/Requirements/Requirements.rst

··· 45 #. `Other RCU Flavors`_ 46 #. `Possible Future Changes`_ 47 48 - This is followed by a `summary <#Summary>`__, however, the answers to 49 each quick quiz immediately follows the quiz. Select the big white space 50 with your mouse to see the answer. 51 ··· 1096 | case, voluntary context switch) within an RCU read-side critical | 1097 | section. However, sleeping locks may be used within userspace RCU | 1098 | read-side critical sections, and also within Linux-kernel sleepable | 1099 - | RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In | 1100 | addition, the -rt patchset turns spinlocks into a sleeping locks so | 1101 | that the corresponding critical sections can be preempted, which also | 1102 | means that these sleeplockified spinlocks (but not other sleeping | ··· 1186 RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__ 1187 was born. Josh Triplett has since taken over the small-memory banner 1188 with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__ 1189 - project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional 1190 for those kernels not needing it. 1191 1192 The remaining performance requirements are, for the most part, ··· 1457 the relevant Kconfig options and kernel boot parameters. RCU currently 1458 does not do much sanity checking of these parameters, so please use 1459 caution when changing them. Note that these forward-progress measures 1460 - are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks 1461 - RCU <#Tasks%20RCU>`__. 1462 1463 RCU takes the following steps in ``call_rcu()`` to encourage timely 1464 invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has ··· 1477 1478 Again, these are default values when running at ``HZ=1000``, and can be 1479 overridden. Again, these forward-progress measures are provided only for 1480 - RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks 1481 - RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward 1482 progress for ``rcu_nocbs`` CPUs is much less well-developed, in part 1483 because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke 1484 ``call_rcu()`` relatively infrequently. If workloads emerge that need ··· 1920 1921 The Linux kernel supports CPU hotplug, which means that CPUs can come 1922 and go. It is of course illegal to use any RCU API member from an 1923 - offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side 1924 critical sections. This requirement was present from day one in 1925 DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug 1926 implementation is “interesting.” ··· 2177 However, RCU must be reliably informed as to whether any given CPU is 2178 currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that 2179 CPU is executing in usermode, as discussed 2180 - `earlier <#Energy%20Efficiency>`__. It also requires that the 2181 scheduling-clock interrupt be enabled when RCU needs it to be: 2182 2183 #. If a CPU is either idle or executing in usermode, and RCU believes it ··· 2294 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2295 2296 Expanding on the `earlier 2297 - discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by 2298 hot code paths in performance-critical portions of the Linux kernel's 2299 networking, security, virtualization, and scheduling code paths. RCU 2300 must therefore use efficient implementations, especially in its

··· 45 #. `Other RCU Flavors`_ 46 #. `Possible Future Changes`_ 47 48 + This is followed by a summary_, however, the answers to 49 each quick quiz immediately follows the quiz. Select the big white space 50 with your mouse to see the answer. 51 ··· 1096 | case, voluntary context switch) within an RCU read-side critical | 1097 | section. However, sleeping locks may be used within userspace RCU | 1098 | read-side critical sections, and also within Linux-kernel sleepable | 1099 + | RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In | 1100 | addition, the -rt patchset turns spinlocks into a sleeping locks so | 1101 | that the corresponding critical sections can be preempted, which also | 1102 | means that these sleeplockified spinlocks (but not other sleeping | ··· 1186 RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__ 1187 was born. Josh Triplett has since taken over the small-memory banner 1188 with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__ 1189 + project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional 1190 for those kernels not needing it. 1191 1192 The remaining performance requirements are, for the most part, ··· 1457 the relevant Kconfig options and kernel boot parameters. RCU currently 1458 does not do much sanity checking of these parameters, so please use 1459 caution when changing them. Note that these forward-progress measures 1460 + are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks 1461 + RCU`_. 1462 1463 RCU takes the following steps in ``call_rcu()`` to encourage timely 1464 invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has ··· 1477 1478 Again, these are default values when running at ``HZ=1000``, and can be 1479 overridden. Again, these forward-progress measures are provided only for 1480 + RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks 1481 + RCU`_. Even for RCU, callback-invocation forward 1482 progress for ``rcu_nocbs`` CPUs is much less well-developed, in part 1483 because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke 1484 ``call_rcu()`` relatively infrequently. If workloads emerge that need ··· 1920 1921 The Linux kernel supports CPU hotplug, which means that CPUs can come 1922 and go. It is of course illegal to use any RCU API member from an 1923 + offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side 1924 critical sections. This requirement was present from day one in 1925 DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug 1926 implementation is “interesting.” ··· 2177 However, RCU must be reliably informed as to whether any given CPU is 2178 currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that 2179 CPU is executing in usermode, as discussed 2180 + `earlier <Energy Efficiency_>`__. It also requires that the 2181 scheduling-clock interrupt be enabled when RCU needs it to be: 2182 2183 #. If a CPU is either idle or executing in usermode, and RCU believes it ··· 2294 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2295 2296 Expanding on the `earlier 2297 + discussion <Performance and Scalability_>`__, RCU is used heavily by 2298 hot code paths in performance-critical portions of the Linux kernel's 2299 networking, security, virtualization, and scheduling code paths. RCU 2300 must therefore use efficient implementations, especially in its

+2 -2

Documentation/admin-guide/binfmt-misc.rst

··· 23 24 - ``name`` 25 is an identifier string. A new /proc file will be created with this 26 - ``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for 27 obvious reasons. 28 - ``type`` 29 is the type of recognition. Give ``M`` for magic and ``E`` for extension. ··· 83 ``F`` - fix binary 84 The usual behaviour of binfmt_misc is to spawn the 85 binary lazily when the misc format file is invoked. However, 86 - this doesn``t work very well in the face of mount namespaces and 87 changeroots, so the ``F`` mode opens the binary as soon as the 88 emulation is installed and uses the opened image to spawn the 89 emulator, meaning it is always available once installed,

··· 23 24 - ``name`` 25 is an identifier string. A new /proc file will be created with this 26 + name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for 27 obvious reasons. 28 - ``type`` 29 is the type of recognition. Give ``M`` for magic and ``E`` for extension. ··· 83 ``F`` - fix binary 84 The usual behaviour of binfmt_misc is to spawn the 85 binary lazily when the misc format file is invoked. However, 86 + this doesn't work very well in the face of mount namespaces and 87 changeroots, so the ``F`` mode opens the binary as soon as the 88 emulation is installed and uses the opened image to spawn the 89 emulator, meaning it is always available once installed,

+1 -1

Documentation/admin-guide/bootconfig.rst

··· 154 Because of this "piggyback" method, there is no need to change or 155 update the boot loader and the kernel image itself as long as the boot 156 loader passes the correct initrd file size. If by any chance, the boot 157 - loader passes a longer size, the kernel feils to find the bootconfig data. 158 159 To do this operation, Linux kernel provides "bootconfig" command under 160 tools/bootconfig, which allows admin to apply or delete the config file

··· 154 Because of this "piggyback" method, there is no need to change or 155 update the boot loader and the kernel image itself as long as the boot 156 loader passes the correct initrd file size. If by any chance, the boot 157 + loader passes a longer size, the kernel fails to find the bootconfig data. 158 159 To do this operation, Linux kernel provides "bootconfig" command under 160 tools/bootconfig, which allows admin to apply or delete the config file

+2 -2

Documentation/admin-guide/kernel-parameters.rst

··· 3 The kernel's command-line parameters 4 ==================================== 5 6 - The following is a consolidated list of the kernel parameters as 7 - implemented by the __setup(), core_param() and module_param() macros 8 and sorted into English Dictionary order (defined as ignoring all 9 punctuation and sorting digits before letters in a case insensitive 10 manner), and with descriptions where known.

··· 3 The kernel's command-line parameters 4 ==================================== 5 6 + The following is a consolidated list of the kernel parameters as implemented 7 + by the __setup(), early_param(), core_param() and module_param() macros 8 and sorted into English Dictionary order (defined as ignoring all 9 punctuation and sorting digits before letters in a case insensitive 10 manner), and with descriptions where known.

+6 -6

Documentation/admin-guide/kernel-parameters.txt

··· 1385 1386 ftrace_filter=[function-list] 1387 [FTRACE] Limit the functions traced by the function 1388 - tracer at boot up. function-list is a comma separated 1389 list of functions. This list can be changed at run 1390 time by the set_ftrace_filter file in the debugfs 1391 tracing directory. ··· 1399 ftrace_graph_filter=[function-list] 1400 [FTRACE] Limit the top level callers functions traced 1401 by the function graph tracer at boot up. 1402 - function-list is a comma separated list of functions 1403 that can be changed at run time by the 1404 set_graph_function file in the debugfs tracing directory. 1405 1406 ftrace_graph_notrace=[function-list] 1407 [FTRACE] Do not trace from the functions specified in 1408 - function-list. This list is a comma separated list of 1409 functions that can be changed at run time by the 1410 set_graph_notrace file in the debugfs tracing directory. 1411 ··· 2421 when set. 2422 Format: <int> 2423 2424 - libata.force= [LIBATA] Force configurations. The format is comma 2425 separated list of "[ID:]VAL" where ID is 2426 PORT[.DEVICE]. PORT and DEVICE are decimal numbers 2427 matching port, link or device. Basically, it matches ··· 5145 5146 stacktrace_filter=[function-list] 5147 [FTRACE] Limit the functions that the stack tracer 5148 - will trace at boot up. function-list is a comma separated 5149 list of functions. This list can be changed at run 5150 time by the stack_trace_filter file in the debugfs 5151 tracing directory. Note, this enables stack tracing ··· 5348 trace_event=[event-list] 5349 [FTRACE] Set and start specified trace events in order 5350 to facilitate early boot debugging. The event-list is a 5351 - comma separated list of trace events to enable. See 5352 also Documentation/trace/events.rst 5353 5354 trace_options=[option-list]

··· 1385 1386 ftrace_filter=[function-list] 1387 [FTRACE] Limit the functions traced by the function 1388 + tracer at boot up. function-list is a comma-separated 1389 list of functions. This list can be changed at run 1390 time by the set_ftrace_filter file in the debugfs 1391 tracing directory. ··· 1399 ftrace_graph_filter=[function-list] 1400 [FTRACE] Limit the top level callers functions traced 1401 by the function graph tracer at boot up. 1402 + function-list is a comma-separated list of functions 1403 that can be changed at run time by the 1404 set_graph_function file in the debugfs tracing directory. 1405 1406 ftrace_graph_notrace=[function-list] 1407 [FTRACE] Do not trace from the functions specified in 1408 + function-list. This list is a comma-separated list of 1409 functions that can be changed at run time by the 1410 set_graph_notrace file in the debugfs tracing directory. 1411 ··· 2421 when set. 2422 Format: <int> 2423 2424 + libata.force= [LIBATA] Force configurations. The format is comma- 2425 separated list of "[ID:]VAL" where ID is 2426 PORT[.DEVICE]. PORT and DEVICE are decimal numbers 2427 matching port, link or device. Basically, it matches ··· 5145 5146 stacktrace_filter=[function-list] 5147 [FTRACE] Limit the functions that the stack tracer 5148 + will trace at boot up. function-list is a comma-separated 5149 list of functions. This list can be changed at run 5150 time by the stack_trace_filter file in the debugfs 5151 tracing directory. Note, this enables stack tracing ··· 5348 trace_event=[event-list] 5349 [FTRACE] Set and start specified trace events in order 5350 to facilitate early boot debugging. The event-list is a 5351 + comma-separated list of trace events to enable. See 5352 also Documentation/trace/events.rst 5353 5354 trace_options=[option-list]

+1 -1

Documentation/admin-guide/mm/concepts.rst

··· 184 of the system. When the system is not loaded, most of the memory is free 185 and allocation requests will be satisfied immediately from the free 186 pages supply. As the load increases, the amount of the free pages goes 187 - down and when it reaches a certain threshold (high watermark), an 188 allocation request will awaken the ``kswapd`` daemon. It will 189 asynchronously scan memory pages and either just free them if the data 190 they contain is available elsewhere, or evict to the backing storage

··· 184 of the system. When the system is not loaded, most of the memory is free 185 and allocation requests will be satisfied immediately from the free 186 pages supply. As the load increases, the amount of the free pages goes 187 + down and when it reaches a certain threshold (low watermark), an 188 allocation request will awaken the ``kswapd`` daemon. It will 189 asynchronously scan memory pages and either just free them if the data 190 they contain is available elsewhere, or evict to the backing storage

-1

Documentation/core-api/index.rst

··· 53 .. toctree:: 54 :maxdepth: 1 55 56 - atomic_ops 57 refcount-vs-atomic 58 irq/index 59 local_ops

··· 53 .. toctree:: 54 :maxdepth: 1 55 56 refcount-vs-atomic 57 irq/index 58 local_ops

+16 -16

Documentation/doc-guide/sphinx.rst

··· 48 those versions, you should run ``pip install 'docutils==0.12'``. 49 50 #) It is recommended to use the RTD theme for html output. Depending 51 - on the Sphinx version, it should be installed in separate, 52 with ``pip install sphinx_rtd_theme``. 53 54 - #) Some ReST pages contain math expressions. Due to the way Sphinx work, 55 those expressions are written using LaTeX notation. It needs texlive 56 - installed with amdfonts and amsmath in order to evaluate them. 57 58 In summary, if you want to install Sphinx version 1.7.9, you should do:: 59 ··· 128 ============ 129 130 The usual way to generate the documentation is to run ``make htmldocs`` or 131 - ``make pdfdocs``. There are also other formats available, see the documentation 132 section of ``make help``. The generated documentation is placed in 133 format-specific subdirectories under ``Documentation/output``. 134 ··· 303 - head col 3 304 - head col 4 305 306 - * - column 1 307 - field 1.1 308 - field 1.2 with autospan 309 310 - * - column 2 311 - field 2.1 312 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 313 314 * .. _`last row`: 315 316 - - column 3 317 318 Rendered as: 319 ··· 325 - head col 3 326 - head col 4 327 328 - * - column 1 329 - field 1.1 330 - field 1.2 with autospan 331 332 - * - column 2 333 - field 2.1 334 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 335 336 * .. _`last row`: 337 338 - - column 3 339 340 Cross-referencing 341 ----------------- ··· 361 362 If you want to add an image, you should use the ``kernel-figure`` and 363 ``kernel-image`` directives. E.g. to insert a figure with a scalable 364 - image format use SVG (:ref:`svg_image_example`):: 365 366 .. kernel-figure:: svg_image.svg 367 :alt: simple SVG image ··· 375 376 SVG image example 377 378 - The kernel figure (and image) directive support **DOT** formatted files, see 379 380 * DOT: http://graphviz.org/pdf/dotguide.pdf 381 * Graphviz: http://www.graphviz.org/content/dot-language ··· 394 395 DOT's hello world example 396 397 - Embed *render* markups (or languages) like Graphviz's **DOT** is provided by the 398 ``kernel-render`` directives.:: 399 400 .. kernel-render:: DOT ··· 406 } 407 408 How this will be rendered depends on the installed tools. If Graphviz is 409 - installed, you will see an vector image. If not the raw markup is inserted as 410 *literal-block* (:ref:`hello_dot_render`). 411 412 .. _hello_dot_render: ··· 421 422 The *render* directive has all the options known from the *figure* directive, 423 plus option ``caption``. If ``caption`` has a value, a *figure* node is 424 - inserted. If not, a *image* node is inserted. A ``caption`` is also needed, if 425 - you want to refer it (:ref:`hello_svg_render`). 426 427 Embedded **SVG**:: 428

··· 48 those versions, you should run ``pip install 'docutils==0.12'``. 49 50 #) It is recommended to use the RTD theme for html output. Depending 51 + on the Sphinx version, it should be installed separately, 52 with ``pip install sphinx_rtd_theme``. 53 54 + #) Some ReST pages contain math expressions. Due to the way Sphinx works, 55 those expressions are written using LaTeX notation. It needs texlive 56 + installed with amsfonts and amsmath in order to evaluate them. 57 58 In summary, if you want to install Sphinx version 1.7.9, you should do:: 59 ··· 128 ============ 129 130 The usual way to generate the documentation is to run ``make htmldocs`` or 131 + ``make pdfdocs``. There are also other formats available: see the documentation 132 section of ``make help``. The generated documentation is placed in 133 format-specific subdirectories under ``Documentation/output``. 134 ··· 303 - head col 3 304 - head col 4 305 306 + * - row 1 307 - field 1.1 308 - field 1.2 with autospan 309 310 + * - row 2 311 - field 2.1 312 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 313 314 * .. _`last row`: 315 316 + - row 3 317 318 Rendered as: 319 ··· 325 - head col 3 326 - head col 4 327 328 + * - row 1 329 - field 1.1 330 - field 1.2 with autospan 331 332 + * - row 2 333 - field 2.1 334 - :rspan:`1` :cspan:`1` field 2.2 - 3.3 335 336 * .. _`last row`: 337 338 + - row 3 339 340 Cross-referencing 341 ----------------- ··· 361 362 If you want to add an image, you should use the ``kernel-figure`` and 363 ``kernel-image`` directives. E.g. to insert a figure with a scalable 364 + image format, use SVG (:ref:`svg_image_example`):: 365 366 .. kernel-figure:: svg_image.svg 367 :alt: simple SVG image ··· 375 376 SVG image example 377 378 + The kernel figure (and image) directive supports **DOT** formatted files, see 379 380 * DOT: http://graphviz.org/pdf/dotguide.pdf 381 * Graphviz: http://www.graphviz.org/content/dot-language ··· 394 395 DOT's hello world example 396 397 + Embedded *render* markups (or languages) like Graphviz's **DOT** are provided by the 398 ``kernel-render`` directives.:: 399 400 .. kernel-render:: DOT ··· 406 } 407 408 How this will be rendered depends on the installed tools. If Graphviz is 409 + installed, you will see a vector image. If not, the raw markup is inserted as 410 *literal-block* (:ref:`hello_dot_render`). 411 412 .. _hello_dot_render: ··· 421 422 The *render* directive has all the options known from the *figure* directive, 423 plus option ``caption``. If ``caption`` has a value, a *figure* node is 424 + inserted. If not, an *image* node is inserted. A ``caption`` is also needed, if 425 + you want to refer to it (:ref:`hello_svg_render`). 426 427 Embedded **SVG**:: 428

+4 -4

Documentation/kernel-hacking/locking.rst

··· 118 your task will suspend itself, and be woken up when the mutex is 119 released. This means the CPU can do something else while you are 120 waiting. There are many cases when you simply can't sleep (see 121 - `What Functions Are Safe To Call From Interrupts? <#sleeping-things>`__), 122 and so have to use a spinlock instead. 123 124 Neither type of lock is recursive: see 125 - `Deadlock: Simple and Advanced <#deadlock>`__. 126 127 Locks and Uniprocessor Kernels 128 ------------------------------ ··· 179 180 Note that you can also use spin_lock_irq() or 181 spin_lock_irqsave() here, which stop hardware interrupts 182 - as well: see `Hard IRQ Context <#hard-irq-context>`__. 183 184 This works perfectly for UP as well: the spin lock vanishes, and this 185 macro simply becomes local_bh_disable() ··· 230 ~~~~~~~~~~~~~~~~ 231 232 The same softirq can run on the other CPUs: you can use a per-CPU array 233 - (see `Per-CPU Data <#per-cpu-data>`__) for better performance. If you're 234 going so far as to use a softirq, you probably care about scalable 235 performance enough to justify the extra complexity. 236

··· 118 your task will suspend itself, and be woken up when the mutex is 119 released. This means the CPU can do something else while you are 120 waiting. There are many cases when you simply can't sleep (see 121 + `What Functions Are Safe To Call From Interrupts?`_), 122 and so have to use a spinlock instead. 123 124 Neither type of lock is recursive: see 125 + `Deadlock: Simple and Advanced`_. 126 127 Locks and Uniprocessor Kernels 128 ------------------------------ ··· 179 180 Note that you can also use spin_lock_irq() or 181 spin_lock_irqsave() here, which stop hardware interrupts 182 + as well: see `Hard IRQ Context`_. 183 184 This works perfectly for UP as well: the spin lock vanishes, and this 185 macro simply becomes local_bh_disable() ··· 230 ~~~~~~~~~~~~~~~~ 231 232 The same softirq can run on the other CPUs: you can use a per-CPU array 233 + (see `Per-CPU Data`_) for better performance. If you're 234 going so far as to use a softirq, you probably care about scalable 235 performance enough to justify the extra complexity. 236

+2 -4

Documentation/process/4.Coding.rst

··· 249 of these options should be turned on for any kernel used for development or 250 testing purposes. In particular, you should turn on: 251 252 - - ENABLE_MUST_CHECK and FRAME_WARN to get an 253 - extra set of warnings for problems like the use of deprecated interfaces 254 - or ignoring an important return value from a function. The output 255 - generated by these warnings can be verbose, but one need not worry about 256 warnings from other parts of the kernel. 257 258 - DEBUG_OBJECTS will add code to track the lifetime of various objects

··· 249 of these options should be turned on for any kernel used for development or 250 testing purposes. In particular, you should turn on: 251 252 + - FRAME_WARN to get warnings for stack frames larger than a given amount. 253 + The output generated can be verbose, but one need not worry about 254 warnings from other parts of the kernel. 255 256 - DEBUG_OBJECTS will add code to track the lifetime of various objects

+8 -8

Documentation/sound/kernel-api/writing-an-alsa-driver.rst

··· 71 The codes for PCM and mixer OSS emulation modules are stored in this 72 directory. The rawmidi OSS emulation is included in the ALSA rawmidi 73 code since it's quite small. The sequencer code is stored in 74 - ``core/seq/oss`` directory (see `below <#core-seq-oss>`__). 75 76 core/seq 77 ~~~~~~~~ ··· 382 Each time the ``probe`` callback is called, check the availability of 383 the device. If not available, simply increment the device index and 384 returns. dev will be incremented also later (`step 7 385 - <#set-the-pci-driver-data-and-return-zero>`__). 386 387 2) Create a card instance 388 ~~~~~~~~~~~~~~~~~~~~~~~~~ ··· 450 5) Create other components, such as mixer, MIDI, etc. 451 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 452 453 - Here you define the basic components such as `PCM <#PCM-Interface>`__, 454 - mixer (e.g. `AC97 <#API-for-AC97-Codec>`__), MIDI (e.g. 455 - `MPU-401 <#MIDI-MPU401-UART-Interface>`__), and other interfaces. 456 - Also, if you want a `proc file <#Proc-Interface>`__, define it here, 457 too. 458 459 6) Register the card instance. ··· 941 chip->irq = pci->irq; 942 943 where :c:func:`snd_mychip_interrupt()` is the interrupt handler 944 - defined `later <#pcm-interface-interrupt-handler>`__. Note that 945 ``chip->irq`` should be defined only when :c:func:`request_irq()` 946 succeeded. 947 ··· 3104 3105 If the MPU-401 interface shares its interrupt with the other logical 3106 devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see 3107 - `below <#MIDI-Interrupt-Handler>`__). 3108 3109 Usually, the port address corresponds to the command port and port + 1 3110 corresponds to the data port. If not, you may change the ``cport``

··· 71 The codes for PCM and mixer OSS emulation modules are stored in this 72 directory. The rawmidi OSS emulation is included in the ALSA rawmidi 73 code since it's quite small. The sequencer code is stored in 74 + ``core/seq/oss`` directory (see `below <core/seq/oss_>`__). 75 76 core/seq 77 ~~~~~~~~ ··· 382 Each time the ``probe`` callback is called, check the availability of 383 the device. If not available, simply increment the device index and 384 returns. dev will be incremented also later (`step 7 385 + <7) Set the PCI driver data and return zero._>`__). 386 387 2) Create a card instance 388 ~~~~~~~~~~~~~~~~~~~~~~~~~ ··· 450 5) Create other components, such as mixer, MIDI, etc. 451 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 452 453 + Here you define the basic components such as `PCM <PCM Interface_>`__, 454 + mixer (e.g. `AC97 <API for AC97 Codec_>`__), MIDI (e.g. 455 + `MPU-401 <MIDI (MPU401-UART) Interface_>`__), and other interfaces. 456 + Also, if you want a `proc file <Proc Interface_>`__, define it here, 457 too. 458 459 6) Register the card instance. ··· 941 chip->irq = pci->irq; 942 943 where :c:func:`snd_mychip_interrupt()` is the interrupt handler 944 + defined `later <PCM Interrupt Handler_>`__. Note that 945 ``chip->irq`` should be defined only when :c:func:`request_irq()` 946 succeeded. 947 ··· 3104 3105 If the MPU-401 interface shares its interrupt with the other logical 3106 devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see 3107 + `below <MIDI Interrupt Handler_>`__). 3108 3109 Usually, the port address corresponds to the command port and port + 1 3110 corresponds to the data port. If not, you may change the ``cport``

-1

MAINTAINERS

··· 10260 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev 10261 F: Documentation/atomic_bitops.txt 10262 F: Documentation/atomic_t.txt 10263 - F: Documentation/core-api/atomic_ops.rst 10264 F: Documentation/core-api/refcount-vs-atomic.rst 10265 F: Documentation/litmus-tests/ 10266 F: Documentation/memory-barriers.txt

··· 10260 T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git dev 10261 F: Documentation/atomic_bitops.txt 10262 F: Documentation/atomic_t.txt 10263 F: Documentation/core-api/refcount-vs-atomic.rst 10264 F: Documentation/litmus-tests/ 10265 F: Documentation/memory-barriers.txt