Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752009AbcJKHlT (ORCPT ); Tue, 11 Oct 2016 03:41:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46082 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751635AbcJKHlS (ORCPT ); Tue, 11 Oct 2016 03:41:18 -0400 Date: Tue, 11 Oct 2016 15:41:11 +0800 From: Baoquan He To: "Eric W. Biederman" Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, akpm@linux-foundation.org, mingo@redhat.com, hpa@zytor.com, dyoung@redhat.com, tonli@redhat.com, keescook@chromium.org, takahiro.akashi@linaro.org, thgarnie@google.com, ats-kumagai@wm.jp.nec.com Subject: Re: [PATCH] kexec: Export memory sections virtual addresses to vmcoreinfo Message-ID: <20161011074111.GD11185@x1> References: <1475743561-23912-1-git-send-email-bhe@redhat.com> <877f9lckbq.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877f9lckbq.fsf@x220.int.ebiederm.org> User-Agent: Mutt/1.7.0 (2016-08-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 11 Oct 2016 07:41:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1825 Lines: 41 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 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