linux-toradex.git/Documentation/admin-guide/kdump, branch master

docs: fix 're-use' -> 'reuse' in documentation

2026-02-02T16:54:15+00:00

Signed-off-by: Rhys Tumelty 
Acked-by: Randy Dunlap 
Signed-off-by: Jonathan Corbet 
Message-ID: <20260128220233.179439-1-rhys@tumelty.co.uk>

Documentation: use a source-read extension for the index link boilerplate

2026-01-23T18:59:34+00:00

The root document usually has a special :ref:`genindex` link to the
generated index. This is also the case for Documentation/index.rst. The
other index.rst files deeper in the directory hierarchy usually don't.

For SPHINXDIRS builds, the root document isn't Documentation/index.rst,
but some other index.rst in the hierarchy. Currently they have a
".. only::" block to add the index link when doing SPHINXDIRS html
builds.

This is obviously very tedious and repetitive. The link is also added to
all index.rst files in the hierarchy for SPHINXDIRS builds, not just the
root document.

Put the boilerplate in a sphinx-includes/subproject-index.rst file, and
include it at the end of the root document for subproject builds in an
ad-hoc source-read extension defined in conf.py.

For now, keep having the boilerplate in translations, because this
approach currently doesn't cover translated index link headers.

Cc: Jonathan Corbet 
Cc: Mauro Carvalho Chehab 
Cc: Randy Dunlap 
Signed-off-by: Jani Nikula 
Tested-by: Mauro Carvalho Chehab 
Reviewed-by: Mauro Carvalho Chehab 
[jc: did s/doctree/kern_doc_dir/ ]
Signed-off-by: Jonathan Corbet 
Message-ID: <20260123143149.2024303-1-jani.nikula@intel.com>

Documentation: Fix admin-guide typos

2025-08-18T16:31:19+00:00

Fix typos.

Signed-off-by: Bjorn Helgaas 
Reviewed-by: Randy Dunlap 
Signed-off-by: Jonathan Corbet 
Link: https://lore.kernel.org/r/20250813200526.290420-4-helgaas@kernel.org

Merge tag 'mm-nonmm-stable-2025-08-03-12-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

2025-08-03T23:23:09+00:00

Pull non-MM updates from Andrew Morton:
 "Significant patch series in this pull request:

   - "squashfs: Remove page->mapping references" (Matthew Wilcox) gets
     us closer to being able to remove page->mapping

   - "relayfs: misc changes" (Jason Xing) does some maintenance and
     minor feature addition work in relayfs

   - "kdump: crashkernel reservation from CMA" (Jiri Bohac) switches
     us from static preallocation of the kdump crashkernel's working
     memory over to dynamic allocation. So the difficulty of a-priori
     estimation of the second kernel's needs is removed and the first
     kernel obtains extra memory

   - "generalize panic_print's dump function to be used by other
     kernel parts" (Feng Tang) implements some consolidation and
     rationalization of the various ways in which a failing kernel
     splats information at the operator

* tag 'mm-nonmm-stable-2025-08-03-12-47' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (80 commits)
  tools/getdelays: add backward compatibility for taskstats version
  kho: add test for kexec handover
  delaytop: enhance error logging and add PSI feature description
  samples: Kconfig: fix spelling mistake "instancess" -> "instances"
  fat: fix too many log in fat_chain_add()
  scripts/spelling.txt: add notifer||notifier to spelling.txt
  xen/xenbus: fix typo "notifer"
  net: mvneta: fix typo "notifer"
  drm/xe: fix typo "notifer"
  cxl: mce: fix typo "notifer"
  KVM: x86: fix typo "notifer"
  MAINTAINERS: add maintainers for delaytop
  ucount: use atomic_long_try_cmpxchg() in atomic_long_inc_below()
  ucount: fix atomic_long_inc_below() argument type
  kexec: enable CMA based contiguous allocation
  stackdepot: make max number of pools boot-time configurable
  lib/xxhash: remove unused functions
  init/Kconfig: restore CONFIG_BROKEN help text
  lib/raid6: update recov_rvv.c zero page usage
  docs: update docs after introducing delaytop
  ...

kdump, documentation: describe craskernel CMA reservation

2025-07-20T02:08:23+00:00

Describe the new crashkernel ",cma" suffix in Documentation/

Link: https://lkml.kernel.org/r/aEqpQwUy6gqSiUkV@dwarf.suse.cz
Signed-off-by: Jiri Bohac 
Cc: Baoquan He 
Cc: Dave Young 
Cc: David Hildenbrand 
Cc: Donald Dutile 
Cc: Michal Hocko 
Cc: Philipp Rudo 
Cc: Pingfan Liu 
Cc: Tao Liu 
Cc: Vivek Goyal 
Signed-off-by: Andrew Morton

vmcoreinfo: Remove documentation of PG_slab and PG_hugetlb

2025-06-18T11:06:27+00:00

The changes to kernel/vmcore_info.c were sadly not reflected in the
documentation.  Rectify that for both these flags as well as adding
PAGE_UNACCEPTED_MAPCOUNT_VALUE.

Signed-off-by: Matthew Wilcox (Oracle) 
Acked-by: Harry Yoo 
Link: https://patch.msgid.link/20250611155916.2579160-8-willy@infradead.org
Signed-off-by: Vlastimil Babka

x86/crash: pass dm crypt keys to kdump kernel

2025-05-21T17:48:21+00:00

1st kernel will build up the kernel command parameter dmcryptkeys as
similar to elfcorehdr to pass the memory address of the stored info of dm
crypt key to kdump kernel.

Link: https://lkml.kernel.org/r/20250502011246.99238-8-coxu@redhat.com
Signed-off-by: Coiby Xu 
Acked-by: Baoquan He 
Cc: "Daniel P. Berrange" 
Cc: Dave Hansen 
Cc: Dave Young 
Cc: Jan Pazdziora 
Cc: Liu Pingfan 
Cc: Milan Broz 
Cc: Ondrej Kozina 
Cc: Vitaly Kuznetsov 
Signed-off-by: Andrew Morton

crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging

2025-05-21T17:48:21+00:00

When there are CPU and memory hot un/plugs, the dm crypt keys may need to
be reloaded again depending on the solution for crash hotplug support. 
Currently, there are two solutions.  One is to utilizes udev to instruct
user space to reload the kdump kernel image and initrd, elfcorehdr and etc
again.  The other is to only update the elfcorehdr segment introduced in
commit 247262756121 ("crash: add generic infrastructure for crash hotplug
support").

For the 1st solution, the dm crypt keys need to be reloaded again.  The
user space can write true to /sys/kernel/config/crash_dm_crypt_key/reuse
so the stored keys can be re-used.

For the 2nd solution, the dm crypt keys don't need to be reloaded. 
Currently, only x86 supports the 2nd solution.  If the 2nd solution gets
extended to all arches, this patch can be dropped.

Link: https://lkml.kernel.org/r/20250502011246.99238-5-coxu@redhat.com
Signed-off-by: Coiby Xu 
Acked-by: Baoquan He 
Cc: "Daniel P. Berrange" 
Cc: Dave Hansen 
Cc: Dave Young 
Cc: Jan Pazdziora 
Cc: Liu Pingfan 
Cc: Milan Broz 
Cc: Ondrej Kozina 
Cc: Vitaly Kuznetsov 
Signed-off-by: Andrew Morton

crash_dump: make dm crypt keys persist for the kdump kernel

2025-05-21T17:48:20+00:00

A configfs /sys/kernel/config/crash_dm_crypt_keys is provided for user
space to make the dm crypt keys persist for the kdump kernel.  Take the
case of dumping to a LUKS-encrypted target as an example, here is the life
cycle of the kdump copies of LUKS volume keys,

 1. After the 1st kernel loads the initramfs during boot, systemd uses
    an user-input passphrase to de-crypt the LUKS volume keys or simply
    TPM-sealed volume keys and then save the volume keys to specified
    keyring (using the --link-vk-to-keyring API) and the keys will expire
    within specified time.

 2. A user space tool (kdump initramfs loader like kdump-utils) create
    key items inside /sys/kernel/config/crash_dm_crypt_keys to inform
    the 1st kernel which keys are needed.

 3. When the kdump initramfs is loaded by the kexec_file_load
    syscall, the 1st kernel will iterate created key items, save the
    keys to kdump reserved memory.

 4. When the 1st kernel crashes and the kdump initramfs is booted, the
    kdump initramfs asks the kdump kernel to create a user key using the
    key stored in kdump reserved memory by writing yes to
    /sys/kernel/crash_dm_crypt_keys/restore. Then the LUKS encrypted
    device is unlocked with libcryptsetup's --volume-key-keyring API.

 5. The system gets rebooted to the 1st kernel after dumping vmcore to
    the LUKS encrypted device is finished

Eventually the keys have to stay in the kdump reserved memory for the
kdump kernel to unlock encrypted volumes.  During this process, some
measures like letting the keys expire within specified time are desirable
to reduce security risk.

This patch assumes,
1) there are 128 LUKS devices at maximum to be unlocked thus
   MAX_KEY_NUM=128.

2) a key description won't exceed 128 bytes thus KEY_DESC_MAX_LEN=128.

And here is a demo on how to interact with
/sys/kernel/config/crash_dm_crypt_keys,

    # Add key #1
    mkdir /sys/kernel/config/crash_dm_crypt_keys/7d26b7b4-e342-4d2d-b660-7426b0996720
    # Add key #1's description
    echo cryptsetup:7d26b7b4-e342-4d2d-b660-7426b0996720 > /sys/kernel/config/crash_dm_crypt_keys/description

    # how many keys do we have now?
    cat /sys/kernel/config/crash_dm_crypt_keys/count
    1

    # Add key# 2 in the same way

    # how many keys do we have now?
    cat /sys/kernel/config/crash_dm_crypt_keys/count
    2

    # the tree structure of /crash_dm_crypt_keys configfs
    tree /sys/kernel/config/crash_dm_crypt_keys/
    /sys/kernel/config/crash_dm_crypt_keys/
    ├── 7d26b7b4-e342-4d2d-b660-7426b0996720
    │   └── description
    ├── count
    ├── fce2cd38-4d59-4317-8ce2-1fd24d52c46a
    │   └── description

Link: https://lkml.kernel.org/r/20250502011246.99238-3-coxu@redhat.com
Signed-off-by: Coiby Xu 
Acked-by: Baoquan He 
Cc: "Daniel P. Berrange" 
Cc: Dave Hansen 
Cc: Dave Young 
Cc: Jan Pazdziora 
Cc: Liu Pingfan 
Cc: Milan Broz 
Cc: Ondrej Kozina 
Cc: Vitaly Kuznetsov 
Signed-off-by: Andrew Morton

crash: export PAGE_UNACCEPTED_MAPCOUNT_VALUE to vmcoreinfo

2025-05-12T00:54:04+00:00

On Intel TDX guest, unaccepted memory is unusable free memory which is not
managed by buddy, until it's accepted by guest.  Before that, it cannot be
accessed by the first kernel as well as the kexec'ed kernel.  The kexec'ed
kernel will skip these pages and fill in zero data for the reader of
vmcore.

The dump tool like makedumpfile creates a page descriptor (size 24 bytes)
for each non-free page, including zero data page, but it will not create
descriptor for free pages.  If it is not able to distinguish these
unaccepted pages with zero data pages, a certain amount of space will be
wasted in proportion (~1/170).  In fact, as a special kind of free page
the unaccepted pages should be excluded, like the real free pages.

Export the page type PAGE_UNACCEPTED_MAPCOUNT_VALUE to vmcoreinfo, so that
dump tool can identify whether a page is unaccepted.

[zhiquan1.li@intel.com: fix docs: "Title underline too short" warning]
  Link: https://lore.kernel.org/all/20240809114854.3745464-5-kirill.shutemov@linux.intel.com/
  Link: https://lkml.kernel.org/r/20250405060610.860465-1-zhiquan1.li@intel.com
Link: https://lore.kernel.org/all/20240809114854.3745464-5-kirill.shutemov@linux.intel.com/
Link: https://lkml.kernel.org/r/20250403030801.758687-1-zhiquan1.li@intel.com
Signed-off-by: Zhiquan Li 
Reviewed-by: Kirill A. Shutemov 
Acked-by: Baoquan He 
Cc: Dave Young 
Cc: Vivek Goyal 
Cc: Zhiquan Li 
Signed-off-by: Andrew Morton