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