Removal of the kernel code/data/bss resources does break kexec/kdump

Freeman Zhang freeman.zhang1992 at
Thu Apr 14 03:14:49 PDT 2016

Mr. Torvalds,

I do notice your recent commit:

> commit c4004b02f8e5b9ce357a0bb1641756cc86962664
> Author: Linus Torvalds <torvalds at>
> 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!

More information about the kexec mailing list