[Makedumpfile Patch 0/6] Fix --mem-usage /proc/kcore
ats-kumagai at wm.jp.nec.com
Sun Feb 12 22:26:47 PST 2017
>`makedumpfile --mem-usage /proc/kcore` has been broken after kaslr specific
>modifications. I have proposed a kernel patch  which has been ACKed by
>Andrew Morton and is available in next-2017020 now. Hopefully, it should be
>part of upstream in v4.10 release. This kernel patch helps to fix this
>issue for both the case of kaslr enabled and disabled.
>To seek other's feedback, I am sending makedumpfile patches before kernel
>patch hits upstream.
Thanks for taking care of this feature.
I understand that the problem is:
- phys_base is necessary for VtoP, but:
- SYMBOL(phys_base) is unavailable since /proc/kcore doesn't export VMCOREINFO.
- get_phys_base() doesn't work well since current PT_LOAD doesn't have valid p_paddr.
The new makedumpfile with this patches can show unexpected behavior since it
will refer to invalid p_paddr(always 0). Of course, also current makedumpfile cannot
work if phys_base isn't 0.
If we don't have any way to get phys_base in 1st kernel environment,
I think we should disable this feature in older kernel (e.g. by checking kernel version).
>Baoquan He (2):
> makedumpfile: Correct the calculation of kvaddr in
> makedumpfile: Discard process_dump_load
>Pratyush Anand (4):
> show_mem_usage(): calculate page offset after elf load
> initial(): call cach_init() a bit early
> x86_64: check physical address in PT_LOAD for none direct mapped
> elf_info: kcore: check for invalid physical address
> arch/x86_64.c | 6 ++++--
> elf_info.c | 25 +++++--------------------
> makedumpfile.c | 12 ++++++------
> 3 files changed, 15 insertions(+), 28 deletions(-)
>kexec mailing list
>kexec at lists.infradead.org
More information about the kexec