From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1UZcUc-0005Ly-74 for kexec@lists.infradead.org; Tue, 07 May 2013 07:39:23 +0000 Received: from m3.gw.fujitsu.co.jp (unknown [10.0.50.73]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 340FB3EE0C5 for ; Tue, 7 May 2013 16:38:54 +0900 (JST) Received: from smail (m3 [127.0.0.1]) by outgoing.m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 27B9845DEBB for ; Tue, 7 May 2013 16:38:54 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (s3.gw.fujitsu.co.jp [10.0.50.93]) by m3.gw.fujitsu.co.jp (Postfix) with ESMTP id 1173945DEB6 for ; Tue, 7 May 2013 16:38:54 +0900 (JST) Received: from s3.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 043DA1DB803B for ; Tue, 7 May 2013 16:38:54 +0900 (JST) Received: from m1001.s.css.fujitsu.com (m1001.s.css.fujitsu.com [10.240.81.139]) by s3.gw.fujitsu.co.jp (Postfix) with ESMTP id 9FFC81DB8038 for ; Tue, 7 May 2013 16:38:53 +0900 (JST) Message-ID: <5188AF5C.2070807@jp.fujitsu.com> Date: Tue, 07 May 2013 16:38:04 +0900 From: HATAYAMA Daisuke MIME-Version: 1.0 Subject: Re: [PATCH v4 7/8] vmcore: treat memory chunks referenced by PT_LOAD program header entries in page-size boundary in vmcore_list References: <20130413002000.18245.21513.stgit@localhost6.localdomain6> <20130413002145.18245.73180.stgit@localhost6.localdomain6> <20130429195154.GR8204@redhat.com> In-Reply-To: <20130429195154.GR8204@redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "kexec" Errors-To: kexec-bounces+dwmw2=twosheds.infradead.org@lists.infradead.org To: Vivek Goyal Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, lisa.mitchell@hp.com, kumagai-atsushi@mxc.nes.nec.co.jp, ebiederm@xmission.com, zhangyanfei@cn.fujitsu.com, akpm@linux-foundation.org, cpw@sgi.com, jingbai.ma@hp.com Sorry for late reply. (2013/04/30 4:51), Vivek Goyal wrote: > On Sat, Apr 13, 2013 at 09:21:46AM +0900, HATAYAMA Daisuke wrote: >> Treat memory chunks referenced by PT_LOAD program header entries in >> page-size boundary in vmcore_list. Formally, for each range [start, >> end], we set up the corresponding vmcore object in vmcore_list to >> [rounddown(start, PAGE_SIZE), roundup(end, PAGE_SIZE)]. >> >> This change affects layout of /proc/vmcore. The gaps generated by the >> rearrangement are newly made visible to applications as >> holes. Concretely, they are two ranges [rounddown(start, PAGE_SIZE), >> start] and [end, roundup(end, PAGE_SIZE)]. > > Sorry did not understand this part. So if end is not page aligned, then > we roundup(end, PAGE_SIZE) and increase the PT_LOAD size accordingly? > Similarly for start, we do roundown(). > > - Can you really rounddown() start? Then you will have to change start > virtual address in program header and that's not really a good idea. > No, there's no need to change paddr in program header. Pleaes notice that difference between what objects in vc_list refer to and what PT_LOAD program headers refer to. The former covers not only kernel memory but also the extra memory, while the latter the kernel memory only. > - So this extra memory for end, we read from old memory and not fill > with zeros? Yes. The extra memory is not covered by any program header, i.e. hole. The extra memory is not modified at all, exported with no change; if it is used by BIOS, users can see BIOS data there. This design comes from the discussion with Erick. > >> >> Signed-off-by: HATAYAMA Daisuke >> --- >> >> fs/proc/vmcore.c | 26 ++++++++++++++++++++------ >> 1 files changed, 20 insertions(+), 6 deletions(-) >> >> diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c >> index 029bdc0..cd0f9d9 100644 >> --- a/fs/proc/vmcore.c >> +++ b/fs/proc/vmcore.c >> @@ -477,16 +477,23 @@ static int __init process_ptload_program_headers_elf64(char *elfptr, >> vmcore_off = elfsz + roundup(phdr_ptr->p_memsz, PAGE_SIZE); >> >> for (i = 0; i < ehdr_ptr->e_phnum; i++, phdr_ptr++) { >> + u64 paddr, start, end, size; >> + >> if (phdr_ptr->p_type != PT_LOAD) >> continue; >> >> + paddr = phdr_ptr->p_offset; >> + start = rounddown(paddr, PAGE_SIZE); >> + end = roundup(paddr + phdr_ptr->p_memsz, PAGE_SIZE); >> + size = end - start; >> + >> /* Add this contiguous chunk of memory to vmcore list.*/ >> - if (vmcore_add(vc_list, phdr_ptr->p_offset, phdr_ptr->p_memsz)) >> + if (vmcore_add(vc_list, start, size)) >> return -ENOMEM; >> >> /* Update the program header offset. */ >> - phdr_ptr->p_offset = vmcore_off; >> - vmcore_off = vmcore_off + phdr_ptr->p_memsz; >> + phdr_ptr->p_offset = vmcore_off + (paddr - start); > > What's paddr-start. Why following is not sufficient. > > phdr_ptr->p_offset = vmcore_off > (paddr - start) is offset of the memory program header refers to, from which kernel memory starts. Pictrically: vmcore_off +----------------------+ | extra memory | | (non kernel memory) | phdr->p_offset = +----------------------+ vmcore_off + (paddr - start) | |\ | kernel memory | phdr->p_memsz | |/ +----------------------+ | extra memory | | (non kernel memory) | vmcore_off + size +----------------------+ -- Thanks. HATAYAMA, Daisuke _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec