Skip to content

Commit

Permalink
Merge tag 'docs-6.13' of git://git.lwn.net/linux
Browse files Browse the repository at this point in the history
Pull documentation updates from Jonathan Corbet:
 "Another moderately busy cycle in docsland:

   - Work on Chinese translations has picked up again. Happily, they are
     maintaining the existing translations and not just adding new ones.

   - Some maintenance of the Japanese and Italian translations as well.

   - The removal of the venerable "dontdiff" file. It has long outlived
     its usefulness and contained entries ("parse.*") that would
     actively mask actual source change.

   - The addition of enforcement information to the code-of-conduct
     documentation.

  Along with some build-system fixes and a lot of typo and language
  fixes"

* tag 'docs-6.13' of git://git.lwn.net/linux: (52 commits)
  Documentation/CoC: spell out enforcement for unacceptable behaviors
  docs: fix typos and whitespace in Documentation/process/backporting.rst
  docs/zh_CN: fix one sentence in llvm.rst
  docs: bug-bisect: add a note about bisecting -next
  docs/zh_CN: add the translation of kbuild/llvm.rst
  Documentation: Fix incorrect paths/magic in magic numbers rst
  Documentation/maintainer-tip: Fix typos
  Documentation: Improve crash_kexec_post_notifiers description
  Docs/zh_CN: Translate physical_memory.rst to Simplified Chinese
  Documentation: admin: reorganize kernel-parameters intro
  docs/zh_CN: update the translation of process/programming-language.rst
  docs/zh_CN: update the translation of mm/page_owner.rst
  docs/zh_CN: update the translation of mm/page_table_check.rst
  docs/zh_CN: update the translation of mm/overcommit-accounting.rst
  docs/zh_CN: update the translation of mm/admon/faq.rst
  docs/zh_CN: update the translation of mm/active_mm.rst
  docs/zh_CN: update the translation of mm/hmm.rst
  docs: remove Documentation/dontdiff
  docs/zh_CN: Add a entry in Chinese glossary
  Docs/zh_CN: Fix the pfn calculation error in page_tables.rst
  ...
  • Loading branch information
torvalds committed Nov 20, 2024
2 parents bf9aa14 + c818d5c commit c3cda60
Show file tree
Hide file tree
Showing 68 changed files with 2,892 additions and 657 deletions.
1 change: 1 addition & 0 deletions .mailmap
Original file line number Diff line number Diff line change
Expand Up @@ -730,6 +730,7 @@ Will Deacon <[email protected]> <[email protected]>
Wolfram Sang <[email protected]> <[email protected]>
Wolfram Sang <[email protected]> <[email protected]>
Yakir Yang <[email protected]> <[email protected]>
Yanteng Si <[email protected]> <[email protected]>
Yusuke Goda <[email protected]>
Zack Rusin <[email protected]> <[email protected]>
Zhu Yanjun <[email protected]> <[email protected]>
21 changes: 21 additions & 0 deletions Documentation/admin-guide/bug-bisect.rst
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,27 @@ a fully reliable and straight-forward way to reproduce the regression, too.*
With that the process is complete. Now report the regression as described by
Documentation/admin-guide/reporting-issues.rst.

Bisecting linux-next
--------------------

If you face a problem only happening in linux-next, bisect between the
linux-next branches 'stable' and 'master'. The following commands will start
the process for a linux-next tree you added as a remote called 'next'::

git bisect start
git bisect good next/stable
git bisect bad next/master

The 'stable' branch refers to the state of linux-mainline that the current
linux-next release (found in the 'master' branch) is based on -- the former
thus should be free of any problems that show up in -next, but not in Linus'
tree.

This will bisect across a wide range of changes, some of which you might have
used in earlier linux-next releases without problems. Sadly there is no simple
way to avoid checking them: bisecting from one linux-next release to a later
one (say between 'next-20241020' and 'next-20241021') is impossible, as they
share no common history.

Additional reading material
---------------------------
Expand Down
36 changes: 23 additions & 13 deletions Documentation/admin-guide/kernel-parameters.rst
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,16 @@ kernel command line (/proc/cmdline) and collects module parameters
when it loads a module, so the kernel command line can be used for
loadable modules too.

This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
module. Loadable modules, after being loaded into the running kernel, also
reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
parameters may be changed at runtime by the command
``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``.

Special handling
----------------

Hyphens (dashes) and underscores are equivalent in parameter names, so::

log_buf_len=1M print-fatal-signals=1
Expand All @@ -39,8 +49,8 @@ Double-quotes can be used to protect spaces in values, e.g.::

param="spaces in here"

cpu lists:
----------
cpu lists
~~~~~~~~~

Some kernel parameters take a list of CPUs as a value, e.g. isolcpus,
nohz_full, irqaffinity, rcu_nocbs. The format of this list is:
Expand Down Expand Up @@ -82,12 +92,17 @@ so that "nohz_full=all" is the equivalent of "nohz_full=0-N".
The semantics of "N" and "all" is supported on a level of bitmaps and holds for
all users of bitmap_parselist().

This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
module. Loadable modules, after being loaded into the running kernel, also
reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
parameters may be changed at runtime by the command
``echo -n ${value} > /sys/module/${modulename}/parameters/${parm}``.
Metric suffixes
~~~~~~~~~~~~~~~

The [KMG] suffix is commonly described after a number of kernel
parameter values. 'K', 'M', 'G', 'T', 'P', and 'E' suffixes are allowed.
These letters represent the _binary_ multipliers 'Kilo', 'Mega', 'Giga',
'Tera', 'Peta', and 'Exa', equaling 2^10, 2^20, 2^30, 2^40, 2^50, and
2^60 bytes respectively. Such letter suffixes can also be entirely omitted.

Kernel Build Options
--------------------

The parameters listed below are only valid if certain kernel build options
were enabled and if respective hardware is present. This list should be kept
Expand Down Expand Up @@ -211,10 +226,5 @@ a fixed number of characters. This limit depends on the architecture
and is between 256 and 4096 characters. It is defined in the file
./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.

Finally, the [KMG] suffix is commonly described after a number of kernel
parameter values. These 'K', 'M', and 'G' letters represent the _binary_
multipliers 'Kilo', 'Mega', and 'Giga', equaling 2^10, 2^20, and 2^30
bytes respectively. Such letter suffixes can also be entirely omitted:

.. include:: kernel-parameters.txt
:literal:
22 changes: 16 additions & 6 deletions Documentation/admin-guide/kernel-parameters.txt
Original file line number Diff line number Diff line change
Expand Up @@ -921,12 +921,16 @@
the parameter has no effect.

crash_kexec_post_notifiers
Run kdump after running panic-notifiers and dumping
kmsg. This only for the users who doubt kdump always
succeeds in any situation.
Note that this also increases risks of kdump failure,
because some panic notifiers can make the crashed
kernel more unstable.
Only jump to kdump kernel after running the panic
notifiers and dumping kmsg. This option increases
the risks of a kdump failure, since some panic
notifiers can make the crashed kernel more unstable.
In configurations where kdump may not be reliable,
running the panic notifiers could allow collecting
more data on dmesg, like stack traces from other CPUS
or extra data dumped by panic_print. Note that some
configurations enable this option unconditionally,
like Hyper-V, PowerPC (fadump) and AMD SEV-SNP.

crashkernel=size[KMG][@offset[KMG]]
[KNL,EARLY] Using kexec, Linux can switch to a 'crash kernel'
Expand Down Expand Up @@ -6882,6 +6886,12 @@

reserve_mem=12M:4096:trace trace_instance=boot_map^traceoff^traceprintk@trace,sched,irq

Note, saving the trace buffer across reboots does require that the system
is set up to not wipe memory. For instance, CONFIG_RESET_ATTACK_MITIGATION
can force a memory reset on boot which will clear any trace that was stored.
This is just one of many ways that can clear memory. Make sure your system
keeps the content of memory across reboots before relying on this option.

See also Documentation/trace/debugging.rst


Expand Down
2 changes: 1 addition & 1 deletion Documentation/core-api/cpu_hotplug.rst
Original file line number Diff line number Diff line change
Expand Up @@ -616,7 +616,7 @@ ONLINE section for notifications on online and offline operation::
....
cpuhp_remove_instance(state, &inst2->node);
....
remove_multi_state(state);
cpuhp_remove_multi_state(state);


Testing of hotplug states
Expand Down
4 changes: 2 additions & 2 deletions Documentation/core-api/swiotlb.rst
Original file line number Diff line number Diff line change
Expand Up @@ -295,9 +295,9 @@ slot set.

Fourth, the io_tlb_slot array keeps track of any "padding slots" allocated to
meet alloc_align_mask requirements described above. When
swiotlb_tlb_map_single() allocates bounce buffer space to meet alloc_align_mask
swiotlb_tbl_map_single() allocates bounce buffer space to meet alloc_align_mask
requirements, it may allocate pre-padding space across zero or more slots. But
when swiotbl_tlb_unmap_single() is called with the bounce buffer address, the
when swiotlb_tbl_unmap_single() is called with the bounce buffer address, the
alloc_align_mask value that governed the allocation, and therefore the
allocation of any padding slots, is not known. The "pad_slots" field records
the number of padding slots so that swiotlb_tbl_unmap_single() can free them.
Expand Down
2 changes: 1 addition & 1 deletion Documentation/dev-tools/gcov.rst
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Possible uses:
associated code is never run?)

.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
.. _lcov: http://ltp.sourceforge.net/coverage/lcov.php
.. _lcov: https://github.com/linux-test-project/lcov


Preparation
Expand Down
20 changes: 9 additions & 11 deletions Documentation/dev-tools/kgdb.rst
Original file line number Diff line number Diff line change
Expand Up @@ -75,11 +75,11 @@ supports it for the architecture you are using, you can use hardware
breakpoints if you desire to run with the ``CONFIG_STRICT_KERNEL_RWX``
option turned on, else you need to turn off this option.

Next you should choose one of more I/O drivers to interconnect debugging
Next you should choose one or more I/O drivers to interconnect the debugging
host and debugged target. Early boot debugging requires a KGDB I/O
driver that supports early debugging and the driver must be built into
the kernel directly. Kgdb I/O driver configuration takes place via
kernel or module parameters which you can learn more about in the in the
kernel or module parameters which you can learn more about in the
section that describes the parameter kgdboc.

Here is an example set of ``.config`` symbols to enable or disable for kgdb::
Expand Down Expand Up @@ -201,8 +201,8 @@ Using loadable module or built-in
Configure kgdboc at runtime with sysfs
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

At run time you can enable or disable kgdboc by echoing a parameters
into the sysfs. Here are two examples:
At run time you can enable or disable kgdboc by writing parameters
into sysfs. Here are two examples:

1. Enable kgdboc on ttyS0::

Expand Down Expand Up @@ -329,7 +329,7 @@ ways to activate this feature.

2. Use sysfs before configuring an I/O driver::

echo 1 > /sys/module/kgdb/parameters/kgdb_use_con
echo 1 > /sys/module/debug_core/parameters/kgdb_use_con

.. note::

Expand Down Expand Up @@ -374,10 +374,10 @@ default behavior is always set to 0.
Kernel parameter: ``nokaslr``
-----------------------------

If the architecture that you are using enable KASLR by default,
If the architecture that you are using enables KASLR by default,
you should consider turning it off. KASLR randomizes the
virtual address where the kernel image is mapped and confuse
gdb which resolve kernel symbol address from symbol table
virtual address where the kernel image is mapped and confuses
gdb which resolves addresses of kernel symbols from the symbol table
of vmlinux.

Using kdb
Expand Down Expand Up @@ -631,8 +631,6 @@ automatically changes into kgdb mode.

kgdb

Now disconnect your terminal program and connect gdb in its place

2. At the kdb prompt, disconnect the terminal program and connect gdb in
its place.

Expand Down Expand Up @@ -749,7 +747,7 @@ The kernel debugger is organized into a number of components:
helper functions in some of the other kernel components to make it
possible for kdb to examine and report information about the kernel
without taking locks that could cause a kernel deadlock. The kdb core
contains implements the following functionality.
implements the following functionality.

- A simple shell

Expand Down
2 changes: 1 addition & 1 deletion Documentation/dev-tools/kmsan.rst
Original file line number Diff line number Diff line change
Expand Up @@ -133,7 +133,7 @@ KMSAN shadow memory
-------------------

KMSAN associates a metadata byte (also called shadow byte) with every byte of
kernel memory. A bit in the shadow byte is set iff the corresponding bit of the
kernel memory. A bit in the shadow byte is set if the corresponding bit of the
kernel memory byte is uninitialized. Marking the memory uninitialized (i.e.
setting its shadow bytes to ``0xff``) is called poisoning, marking it
initialized (setting the shadow bytes to ``0x00``) is called unpoisoning.
Expand Down
Loading

0 comments on commit c3cda60

Please sign in to comment.