From patchwork Thu May 15 07:14:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Nan X-Patchwork-Id: 4179721 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id D5B8EBFF02 for ; Thu, 15 May 2014 07:25:11 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 03D58201FE for ; Thu, 15 May 2014 07:25:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2BA97201BA for ; Thu, 15 May 2014 07:25:10 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wkq02-0002UL-K9; Thu, 15 May 2014 07:22:42 +0000 Received: from szxga02-in.huawei.com ([119.145.14.65]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Wkpzz-0001gL-Ab for linux-arm-kernel@lists.infradead.org; Thu, 15 May 2014 07:22:40 +0000 Received: from 172.24.2.119 (EHLO szxeml211-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTU47234; Thu, 15 May 2014 15:21:39 +0800 (CST) Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 15:21:36 +0800 Received: from LGGEML410-HUB.china.huawei.com (10.72.61.106) by szxeml423-hub.china.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 15:21:34 +0800 Received: from kernel-host.huawei (10.107.197.247) by lggeml410-hub.china.huawei.com (10.72.61.106) with Microsoft SMTP Server id 14.3.158.1; Thu, 15 May 2014 15:21:25 +0800 From: Wang Nan To: Russell King , Will Deacon , Simon Horman , Mika Westerberg Subject: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid Date: Thu, 15 May 2014 15:14:30 +0800 Message-ID: <1400138070-24046-1-git-send-email-wangnan0@huawei.com> X-Mailer: git-send-email 1.8.4 MIME-Version: 1.0 X-Originating-IP: [10.107.197.247] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140515_002239_881582_05BA379E X-CRM114-Status: GOOD ( 12.13 ) X-Spam-Score: -1.4 (-) Cc: Wang Nan , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Geng Hui X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patch makes crash dump kernel use arch pfn_valid defined in arch/arm/mm/init.c instead of the one in include/linux/mmzone.h. The goal of this patch is to remove some limitation when kexec loading crash kernel while SPARSEMEM is enabled. Before this patch, if second kernel selects both CRASH_DUMP and SPARSEMEM, the second kernel will recongnize memorys at the same section with itself as valid memory, and prevents ioremap (see arm ioremap code, arm doesn't allow valid memory to be ioremapped again). Which introduces some limitations on positioning the crash kernel. For example: For a platform with SECTION_SIZE_BITS == 28 (256MiB) and crashkernel=128M@0x28000000 in kernel cmdline, the second kernel is loaded at 0x28000000. Kexec puts elfcorehdr at 0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to second kernel. When second kernel start, it tries to use ioremap to retrive its elfcorehrd. In this case, elfcodehdr is at the same section of the second kernel, pfn_valid will recongnize the page as valid, so ioremap will refuse to map it. Even if we put crash kernel at the boundary of two sections (such as 129MB@0x0x28000000 in the above situation), 0x20000000-0x28000000 used by old kernel is still unable to retrived by crash kernel because they are at the same section. This patch makes crash dump kernel use strict (and slow) version of pfn_valid(), which makes crash kernel recongnize memory correctly. Signed-off-by: Wang Nan Cc: Geng Hui Cc: Mika Westerberg Cc: Simon Horman --- arch/arm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index db3c541..795b1d4 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1800,7 +1800,7 @@ config ARCH_SELECT_MEMORY_MODEL def_bool ARCH_SPARSEMEM_ENABLE config HAVE_ARCH_PFN_VALID - def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM + def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM || CRASH_DUMP config HIGHMEM bool "High Memory Support"