On 22.03.21 17:01, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels.We have two users of walk_system_ram_res(), which currently only consideres the first level: a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip IORESOURCE_SYSRAM_DRIVER_MANAGED resources via locate_mem_hole_callback(), so even after this change, we won't be placing kexec images onto dax/kmem and virtio-mem added memory. No change. b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently not adding relevant ranges to the crash elf info, resulting in them not getting dumped via kdump. This change fixes loading a crashkernel via kexec_file_load() and including dax/kmem and virtio-mem added System RAM in the crashdump on x86-64. Note that e.g,, arm64 relies on memblock data and, therefore, always considers all added System RAM already. Let's find all busy IORESOURCE_SYSTEM_RAM resources, making the function behave like walk_system_ram_range(). Cc: Andrew Morton <a...@linux-foundation.org> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> Cc: Dan Williams <dan.j.willi...@intel.com> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Andy Shevchenko <andriy.shevche...@linux.intel.com> Cc: Mauro Carvalho Chehab <mchehab+hua...@kernel.org> Cc: Signed-off-by: David Hildenbrand <da...@redhat.com>
^ My copy-paste action when creating the cc list slipped in a duplicate SO in all 3 patches. I can resend if desired.
-- Thanks, David / dhildenb
