Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757311Ab3EGHi5 (ORCPT ); Tue, 7 May 2013 03:38:57 -0400 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:41114 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755233Ab3EGHi4 (ORCPT ); Tue, 7 May 2013 03:38:56 -0400 X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.9 X-SHieldMailCheckerPolicyVersion: FJ-ISEC-20120718-2 Message-ID: <5188AF5C.2070807@jp.fujitsu.com> Date: Tue, 07 May 2013 16:38:04 +0900 From: HATAYAMA Daisuke User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 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 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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3957 Lines: 100 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/