Merge tag 'docs-6.13' of git://git.lwn.net/linux

Wolfram Sang <wsa@kernel.org> <w.sang@pengutronix.de>

Wolfram Sang <wsa@kernel.org> <wsa@the-dreams.de>

Yakir Yang <kuankuan.y@gmail.com> <ykk@rock-chips.com>

Yanteng Si <si.yanteng@linux.dev> <siyanteng@loongson.cn>

Yusuke Goda <goda.yusuke@renesas.com>

Zack Rusin <zack.rusin@broadcom.com> <zackr@vmware.com>

Zhu Yanjun <zyjzyj2000@gmail.com> <yanjunz@nvidia.com>

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

---------------------------

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

	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:

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

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:

			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'

				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

   ....

   cpuhp_remove_instance(state, &inst2->node);

   ....

   remove_multi_state(state);

   cpuhp_remove_multi_state(state);

Testing of hotplug states