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

[Baoquan He]

On 04/14/16 at 06:14pm, Freeman Zhang wrote:
> 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:

Yes, kdump need this to construct the program header of elf file for
kernel text because users want kernel text included in /proc/vmcore. Now
kexec utility relies on /proc/iomem to get the phisical addr of  _text.
Without /proc/iomem we may need to pass it out or take other ways.

> 
> 
> /* 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
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec