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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux