From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352AbdAYGwE (ORCPT ); Wed, 25 Jan 2017 01:52:04 -0500 Received: from mail-pf0-f176.google.com ([209.85.192.176]:36078 "EHLO mail-pf0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751286AbdAYGwD (ORCPT ); Wed, 25 Jan 2017 01:52:03 -0500 Subject: Re: [PATCH] /proc/kcore: Update physical address for kcore ram and text To: Dave Young References: <20170125062949.GA3423@dhcp-128-65.nay.redhat.com> Cc: linux-kernel@vger.kernel.org, bhe@redhat.com, anderson@redhat.com, kexec@lists.infradead.org From: Pratyush Anand Message-ID: Date: Wed, 25 Jan 2017 12:21:47 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170125062949.GA3423@dhcp-128-65.nay.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Dave, On Wednesday 25 January 2017 11:59 AM, Dave Young wrote: > Hi Pratyush > On 01/25/17 at 10:14am, Pratyush Anand wrote: >> Currently all the p_paddr of PT_LOAD headers are assigned to 0, which is >> not true and could be misleading, since 0 is a valid physical address. > I do not know the history of /proc/kcore, so a question is why the > p_addr was set as 0, if there were some reasons and if this could cause > some risk or breakage. > I do not know why it was 0, which is a valid physical address. But certainly, it might break some user space tools, and those need to be fixed. For example, see following code from kexec-tools kexec/kexec-elf.c:build_mem_phdrs() 435 if ((phdr->p_paddr + phdr->p_memsz) < phdr->p_paddr) { 436 /* The memory address wraps */ 437 if (probe_debug) { 438 fprintf(stderr, "ELF address wrap around\n"); 439 } 440 return -1; 441 } We do not need to perform above check for an invalid physical address. I think, kexec-tools and makedumpfile will need fixup. I already have those fixup which will be sent upstream once this patch makes through. Pro with this approach is that, it will help to calculate variable like page_offset, phys_base from PT_LOAD even when they are randomized and therefore will reduce many variable and version specific values in user space tools. ~Pratyush