From patchwork Fri Aug 19 01:26:52 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 9288979 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 32F62600CB for ; Fri, 19 Aug 2016 01:23:53 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 22D4228A8E for ; Fri, 19 Aug 2016 01:23:53 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1796328A9E; Fri, 19 Aug 2016 01:23:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 3C71028A8E for ; Fri, 19 Aug 2016 01:23:52 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.85_2 #1 (Red Hat Linux)) id 1baYVg-0003Pn-U5; Fri, 19 Aug 2016 01:22:12 +0000 Received: from mail-pf0-x229.google.com ([2607:f8b0:400e:c00::229]) by bombadil.infradead.org with esmtps (Exim 4.85_2 #1 (Red Hat Linux)) id 1baYUZ-0002EO-IJ for linux-arm-kernel@lists.infradead.org; Fri, 19 Aug 2016 01:21:22 +0000 Received: by mail-pf0-x229.google.com with SMTP id x72so3755317pfd.2 for ; Thu, 18 Aug 2016 18:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=h0K3XDfh5V2NifA7HyOW28BoYtgy5v9fTFDlNN/OQno=; b=hPk1SZuC2iHNzxTnms1o1Y0GaHwjAUmbjEdhvBQiiR7JJu76y0feK5UwMScAplfrnZ k9EV6viyY9IErdCMAoTHGkvqkwXKY4/p3CIIHQid/EodHiyJ3A473/SP24uv4k6nrp7f sntSl7Gvdkw5UQ+kfOP+0VWZOFXlyRoBRNAkw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=h0K3XDfh5V2NifA7HyOW28BoYtgy5v9fTFDlNN/OQno=; b=WtnqmqXLJ6yL28XvlqPrLsai0hVrSTse6ikzIunUX2/gA1jF5FU1YwsBCtQVb/iRA5 3zEBdYPTEPCXu01u4eR+CejnM0yub+wERBLSQMUmGl0Pws6vU+0FTyftdccGW5/paGsL vi51U0CxlVxhRhyTjxg2uR4zBhSvhBgyncPuCgbdkcmEQ8x46ZTJlQcLfaKaDhjQ7r0l 46azg/eHS/a4gsk9aMeshb6dNYk3mYrJCptegg+dBqN/P1JuYhCp0O/GMbsVEq1lQOxw DJx6LrFKtcEzRhzqlLP0JNJqkLB8pEbhHD/RkgvYM5BeZBs3SDFOcAFDBrtquW93/bif yQRA== X-Gm-Message-State: AEkoousExMHoqkGgHl2hO2mv8BYJryNW2qtmtrCbZzlCAKKYTTY33gq5Na+WUeZY/A/ufDHv X-Received: by 10.98.17.83 with SMTP id z80mr9441734pfi.38.1471569642186; Thu, 18 Aug 2016 18:20:42 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id q14sm1533243pfi.76.2016.08.18.18.20.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Aug 2016 18:20:41 -0700 (PDT) Date: Fri, 19 Aug 2016 10:26:52 +0900 From: AKASHI Takahiro To: James Morse Subject: Re: [PATCH v24 5/9] arm64: kdump: add kdump support Message-ID: <20160819012651.GE20080@linaro.org> Mail-Followup-To: AKASHI Takahiro , James Morse , catalin.marinas@arm.com, will.deacon@arm.com, geoff@infradead.org, bauerman@linux.vnet.ibm.com, dyoung@redhat.com, mark.rutland@arm.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org References: <20160809015248.28414-2-takahiro.akashi@linaro.org> <20160809015615.28527-1-takahiro.akashi@linaro.org> <20160809015615.28527-3-takahiro.akashi@linaro.org> <57AB586D.3080900@arm.com> <20160818071547.GC20080@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160818071547.GC20080@linaro.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160818_182104_139203_99E522B1 X-CRM114-Status: GOOD ( 44.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, geoff@infradead.org, catalin.marinas@arm.com, will.deacon@arm.com, bauerman@linux.vnet.ibm.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP James, On Thu, Aug 18, 2016 at 04:15:48PM +0900, AKASHI Takahiro wrote: > Hi James, Pratyush, > > Thank you for your testing and reporting an issue. > I've been on vacation until yesterday. > > On Wed, Aug 10, 2016 at 05:38:05PM +0100, James Morse wrote: > > Hi Akashi, > > > > On 09/08/16 02:56, AKASHI Takahiro wrote: > > > On crash dump kernel, all the information about primary kernel's system > > > memory (core image) is available in elf core header. > > > The primary kernel will set aside this header with reserve_elfcorehdr() > > > at boot time and inform crash dump kernel of its location via a new > > > device-tree property, "linux,elfcorehdr". > > > > > > Please note that all other architectures use traditional "elfcorehdr=" > > > kernel parameter for this purpose. > > > > > > Then crash dump kernel will access the primary kernel's memory with > > > copy_oldmem_page(), which reads one page by ioremap'ing it since it does > > > not reside in linear mapping on crash dump kernel. > > > > > > We also need our own elfcorehdr_read() here since the header is placed > > > within crash dump kernel's usable memory. > > > > On Seattle when I panic and boot the kdump kernel, I am unable to read the > > /proc/vmcore file. Instead I get: > > nanook@frikadeller:~$ sudo cp /proc/vmcore / > > [ 174.393875] Unhandled fault: synchronous external abort (0x96000210) at > > 0xffffff80096b6000 > > [ 174.402158] Internal error: : 96000210 [#1] PREEMPT SMP > > [ 174.407370] Modules linked in: > > [ 174.410417] CPU: 6 PID: 2059 Comm: cp Tainted: G S W I 4.8.0-rc1+ #4708 > > [ 174.417799] Hardware name: AMD Overdrive/Supercharger/Default string, BIOS > > ROD1002C 04/08/2016 > > [ 174.426396] task: ffffffc0fdec5780 task.stack: ffffffc0f34bc000 > > [ 174.432313] PC is at __arch_copy_to_user+0x180/0x280 > > [ 174.437274] LR is at copy_oldmem_page+0xac/0xf0 > > [ 174.441791] pc : [] lr : [] pstate: 20000145 > > [ 174.449173] sp : ffffffc0f34bfc90 > > [ 174.452474] x29: ffffffc0f34bfc90 x28: 0000000000000000 > > [ 174.457776] x27: 0000000008000000 x26: 000000000000d000 > > [ 174.463077] x25: 0000000000000001 x24: ffffff8008eb5000 > > [ 174.468378] x23: 0000000000000000 x22: ffffff80096b6000 > > [ 174.473679] x21: 0000000000000001 x20: 0000000030127000 > > [ 174.478979] x19: 0000000000001000 x18: 0000007ff7085d60 > > [ 174.484279] x17: 0000000000429358 x16: ffffff80081d9e88 > > [ 174.489579] x15: 0000007fae377590 x14: 0000000000000000 > > [ 174.494880] x13: 0000000000000000 x12: ffffff8008dd1000 > > [ 174.500180] x11: ffffff80096b6fff x10: ffffff80096b6fff > > [ 174.505480] x9 : 0000000040000000 x8 : ffffff8008db6000 > > [ 174.510781] x7 : ffffff80096b7000 x6 : 0000000030127000 > > [ 174.516082] x5 : 0000000030128000 x4 : 0000000000000000 > > [ 174.521382] x3 : 00e8000000000713 x2 : 0000000000000f80 > > [ 174.526682] x1 : ffffff80096b6000 x0 : 0000000030127000 > > [ 174.531982] > > [ 174.533461] Process cp (pid: 2059, stack limit = 0xffffffc0f34bc020) > > > > [ 174.848448] [] __arch_copy_to_user+0x180/0x280 > > [ 174.854448] [] read_from_oldmem.part.4+0xb4/0xf4 > > [ 174.860615] [] read_vmcore+0x100/0x22c > > [ 174.865919] [] proc_reg_read+0x64/0x90 > > [ 174.871223] [] __vfs_read+0x28/0x108 > > [ 174.876348] [] vfs_read+0x84/0x144 > > [ 174.881301] [] SyS_read+0x44/0xa0 > > [ 174.886167] [] el0_svc_naked+0x24/0x28 > > [ 174.891466] Code: 00000000 00000000 00000000 00000000 (a8c12027) > > [ 174.897562] ---[ end trace 00801b2e35b0cd1f ]--- > > > > > > The offending call is: > > > copy_oldmem_page(0x8000000, 0x00000000385f8000, 0x1000, 0, 1) > > > > This is trying to access the bottom page of memory. From the efi memory map: > > > efi: 0x008000000000-0x008001e7ffff [Runtime Data |RUN| |WB|WT|WC|UC]* > > > efi: 0x008001e80000-0x008001ffffff [Conventional Memory| | |WB|WT|WC|UC] > > > > This page is 'Runtime Data', and marked as nomap by both the original and kdump > > kernels, but copy_oldmem_page() doesn't know this. > > > > In this case because we have already parsed the efi memory map again in the > > kdump kernel and re-marked these regions as nomap, the below hunk fixes the > > problem for me: > > =========================%<========================= > > diff --git a/arch/arm64/kernel/crash_dump.c b/arch/arm64/kernel/crash_dump.c > > index 2dc54d129be1..784d4c30b534 100644 > > --- a/arch/arm64/kernel/crash_dump.c > > +++ b/arch/arm64/kernel/crash_dump.c > > @@ -37,6 +37,11 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf, > > if (!csize) > > return 0; > > > > + if (memblock_is_memory(pfn << PAGE_SHIFT) && > > + !memblock_is_map_memory(pfn << PAGE_SHIFT)) > > + /* skip this nomap memory region, reserved by firmware */ > > + return 0; > > + > > vaddr = ioremap_cache(__pfn_to_phys(pfn), PAGE_SIZE); > > Here I'm wandering why my original code doesn't work. > If !memblock_is_map_memory(), ioremap_cache() would call __ioremap_caller() > and return a valid virtual address mapped in vmalloc area. > > > if (!vaddr) > > return -ENOMEM; > > =========================%<========================= > > > > With this I can copy the vmcore file, and feed it to crash to read dmesg, task > > list etc... > > > > This could be a deeper/wider issue, but I can't see any other users of > > memblock_mark_nomap(). > > Do you think depending on this this 're-learning' is robust enough, or should > > the nomap ranges be described in the vmcoreinfo elf notes? > > The current kexec-tools identifies all the memory regions from > /proc/iomem and there is no way for user space tools to distinguish > "EFI runtime data," or any other nomap memory, from normal "System RAM" > because all those resources are currently marked as "System RAM." > > So I think that such regions should be marked as, say, "reserved," > so that we can exclude those memories from a crush dump file. Can you try the following change? If it fixes your problem, I will post it as a patch. Thanks, -Takahiro AKASHI ===8<=== From 740563e4a437f0d6ecf6e421c91433f9b8f19041 Mon Sep 17 00:00:00 2001 From: AKASHI Takahiro Date: Fri, 19 Aug 2016 09:57:52 +0900 Subject: [PATCH] arm64: mark reserved memblock regions explicitly --- arch/arm64/kernel/setup.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 38eda13..38589b5 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -205,10 +205,15 @@ static void __init request_standard_resources(void) for_each_memblock(memory, region) { res = alloc_bootmem_low(sizeof(*res)); - res->name = "System RAM"; + if (memblock_is_nomap(region)) { + res->name = "reserved"; + res->flags = IORESOURCE_MEM | IORESOURCE_BUSY; + } else { + res->name = "System RAM"; + res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; + } res->start = __pfn_to_phys(memblock_region_memory_base_pfn(region)); res->end = __pfn_to_phys(memblock_region_memory_end_pfn(region)) - 1; - res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; request_resource(&iomem_resource, res);