Hi Eric, Thanks a lot for your reviewing! Sorry for late reply. On 10/06/16 at 03:07pm, Eric W. Biederman wrote: > Baoquan He <bhe at redhat.com> writes: > > > KASLR memory randomization can randomize the base of the physical memory > > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap > > (VMEMMAP_START). These need be exported to VMCOREINFO so that user space > > utility, mainly makedumpfile can use them to identify the base of each > > memory section. Here using VMCOREINFO_NUMBER we can reuse the existing > > struct number_table in makedumpfile to import data easily. > > > > Since they are related to x86_64 only, put them into > > arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE > > together since it's also for x86_64 only. > > *Scratches my head* I would have thought this information would have > better fit in the ELF header. Where it actually has a field for virtual > address. It also has a field for physical address, and a third field > for offset in the file (which is where the kdump finds these things in > memory aftewards). > > Why do we need need more magic vmcoreinfo to handle this? Previously in x86_64, values of PAGE_OFFSET, VMALLOC and VMEMMAP are fixed, makedumpfile also hard codes them. In kexec-tools, we try to get page_offset_base from /proc/kallsyms or search it from /proc/kcore elf header with the help of virtual address of symbol _stext. Then we save it into p_vaddr of kernel text program segment. In kdump kernel, we may assume kernel text has the biggest starting virtual address and search it from vmcore elf header. But I can't think of a way to get the starting virtual address of vmalloc and vmemmap which are necessary for makedumpfile analysis. So it's necessary to add them into VMCOREINFO to let makedumpfile know. Thanks Baoquan
