summaryrefslogtreecommitdiff
path: root/kexec/add_buffer.c
diff options
context:
space:
mode:
authorDavid Hildenbrand <david@redhat.com>2021-03-23 11:01:08 +0100
committerSimon Horman <horms@verge.net.au>2021-04-02 12:04:24 +0200
commit717585968d64b2a833f4e4987cd0bd12551ee1ba (patch)
tree36654de89b7f980a21798bd125789bce6166d892 /kexec/add_buffer.c
parent85721bdd187206df402634ddec81ef94b5e23375 (diff)
crashdump/x86: dump any kind of "System RAM"
Traditionally, we had "System RAM" only on the top level of in the kernel resource tree (-> /proc/iomem). Nowadays, we can also have "System RAM" on lower levels of the tree -- driver-managed device memory that is always detected and added via drivers. Current examples are memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System RAM (virtio_mem)"). Note that in some kernel versions "System RAM (kmem)" was exposed as "System RAM", but similarly, on lower levels of the resource tree. Let's add anything that contains "System RAM" to the elf core header, so it will be dumped for kexec_load(). Handling kexec_file_load() in the kernel is similarly getting fixed [1]. Loading a kdump kernel via "kexec -p -c" ... will result in the kdump kernel to also dump dax/kmem and virtio-mem added System RAM now. Note: We only want to dump this memory, we don't want to add this memory to the memmap of an ordinary kexec'ed kernel ("fast system reboot"). [1] https://lkml.kernel.org/r/20210322160200.19633-1-david@redhat.com Signed-off-by: David Hildenbrand <david@redhat.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Signed-off-by: Simon Horman <horms@verge.net.au>
Diffstat (limited to 'kexec/add_buffer.c')
0 files changed, 0 insertions, 0 deletions