Removal of the kernel code/data/bss resources does break kexec/kdump
Freeman Zhang
freeman.zhang1992 at gmail.com
Thu Apr 14 03:14:49 PDT 2016
Mr. Torvalds,
I do notice your recent commit:
> commit c4004b02f8e5b9ce357a0bb1641756cc86962664
> Author: Linus Torvalds <torvalds at linux-foundation.org>
> Date: Wed Apr 6 13:45:07 2016 -0700
>
> x86: remove the kernel code/data/bss resources from /proc/iomem
>
> Let's see if anybody even notices. I doubt anybody uses this, and it
> does expose addresses that should be randomized, so let's just remove
> the code. It's old and traditional, and it used to be cute, but we
> should have removed this long ago.
>
> If it turns out anybody notices and this breaks something, we'll have to
> revert this, and maybe we'll end up using other approaches instead
> (using %pK or similar). But removing unnecessary code is always the
> preferred option.
Removal of these information causes 'kexec/kdump' to fail in the newer
kernel, as 'kexec/arch/i386/crashdump-x86.c' is coded this way:
/* Read kernel physical load addr from the file returned by proc_iomem()
* (Kernel Code) and store in kexec_info */
static int get_kernel_paddr(struct kexec_info *UNUSED(info),
struct crash_elf_info *elf_info)
{
...
if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
elf_info->kern_paddr_start = start;
dbgprintf("kernel load physical addr start = 0x%016Lx\n",
(unsigned long long)start);
return 0;
}
fprintf(stderr, "Cannot determine kernel physical load addr\n");
return -1;
}
Should we revert this commit, or update kexec/kdump code?
Great respect!
Freeman
More information about the kexec
mailing list