From patchwork Wed May 28 08:44:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Nan X-Patchwork-Id: 4253601 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 BF2AEBF90B for ; Wed, 28 May 2014 08:56:14 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id D2E3F202C8 for ; Wed, 28 May 2014 08:56:13 +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 F3A5F20136 for ; Wed, 28 May 2014 08:56:12 +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 1WpZcO-0000GP-R9; Wed, 28 May 2014 08:53:52 +0000 Received: from szxga03-in.huawei.com ([119.145.14.66]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WpZcC-0008Og-NG; Wed, 28 May 2014 08:53:41 +0000 Received: from 172.24.2.119 (EHLO szxeml205-edg.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id APG21886; Wed, 28 May 2014 16:52:46 +0800 (CST) Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by szxeml205-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 16:52:07 +0800 Received: from LGGEML411-HUB.china.huawei.com (10.72.61.107) by SZXEML454-HUB.china.huawei.com (10.82.67.197) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 28 May 2014 16:52:08 +0800 Received: from kernel-host.huawei (10.107.197.247) by lggeml411-hub.china.huawei.com (10.72.61.107) with Microsoft SMTP Server id 14.3.158.1; Wed, 28 May 2014 16:51:57 +0800 From: Wang Nan To: Russell King , Simon Horman , Will Deacon Subject: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform Date: Wed, 28 May 2014 16:44:28 +0800 Message-ID: <1401266668-34365-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-20140528_015341_439630_8FA92379 X-CRM114-Status: GOOD ( 10.57 ) X-Spam-Score: -1.4 (-) Cc: Wang Nan , kexec@lists.infradead.org, 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 removes an irrational limitation for crash dump kernel on ARM platform with SPARSEMEM enabled. Without this patch, crash reservation area for a crash dump kernel with SPARSEMEM selected must occupy a full section plus 1MiB. If not, elfcorehdr and some memory space used by the first kernel will unable to get accessed. This is caused by pfn_valid: fast pfn_valid ragards any pfn in a valid section as valid and prevents it to be ioremapped. This limitation wastes memory, because sections are always large and crash dump kernel should be as small as possible. This patch selects HAVE_ARCH_PFN_VALID for CRASH_DUMP, makes crash dump kernel to use strict version of pfn_valid(). Signed-off-by: Wang Nan --- This is the third time I post this patch. The previous records can be retrived from: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256498.html http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/257472.html Different from previous version, this patch select HAVE_ARCH_PFN_VALID right after CRASH_DUMP config entry. --- arch/arm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index c57ddcb..d5ffbb1 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2160,6 +2160,7 @@ config ATAGS_PROC config CRASH_DUMP bool "Build kdump crash kernel (EXPERIMENTAL)" + select HAVE_ARCH_PFN_VALID if SPARSEMEM help Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels which are