diff options
| author | Breno Leitao <leitao@debian.org> | 2026-09-21 03:45:42 -0700 |
|---|---|---|
| committer | Christian Brauner <brauner@kernel.org> | 2026-09-25 16:54:48 +0200 |
| commit | 9a82c64e133fdaf6e250dcb25c57e8d0d837ea64 (patch) | |
| tree | d9f0d77a7148ff996d6c655b42d7fc578963f3bb /tools/lib/python | |
| parent | 5045900e1bc444192835838a4d1522288a755818 (diff) | |
| download | linux-next-9a82c64e133fdaf6e250dcb25c57e8d0d837ea64.tar.gz linux-next-9a82c64e133fdaf6e250dcb25c57e8d0d837ea64.zip | |
vmcore: report the release of the crashed kernel
kdump runs in a very small environment and cut-down set of drivers, and
it can die before the dump lands: it runs out of memory, a device hangs
on reset, or a watchdog fires while the dump is still being written out.
This happens about a single high digit percentage on most of big scale
datacenters.
When that happens the only evidence left is what the capture kernel
printed to the console, and that does not say which kernel crashed.
A fleet typically pins one kdump image and boots it after crashes from
many different production kernels, and it is useful to understand what
are the combination of crashed kernel panic and succesful kdump
collection.
Whether the dump completes at all tends to depend on the kernel that
died: memory pinned, devices in flight, dump size.
The release is already recorded. crash_save_vmcoreinfo_init() puts
OSRELEASE= in the VMCOREINFO note, and by the time vmcore_init() has run
parse_crash_elf_headers() that note sits in elfnotes_buf. Walk the notes
for it and print:
vmcore: dump is from kernel 7.3.0-rc3-next-20260917
Given this is cheap and useful, I think it is worth adding to vmcore, to
improve kdump monitoring.
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260921-kdump_print-v1-1-e445fec3177c@debian.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions
