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: 30223 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-pa0-f72.google.com (mail-pa0-f72.google.com [209.85.220.72]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 1D3CD20446 for ; Thu, 15 May 2014 07:21:58 +0000 (UTC) Received: by mail-pa0-f72.google.com with SMTP id rd3sf3619550pab.3 for ; Thu, 15 May 2014 00:21:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:from:to:cc:subject:date:message-id :mime-version:sender:precedence:list-id:x-original-sender :x-original-authentication-results:mailing-list:list-post:list-help :list-archive:list-unsubscribe:content-type; bh=szIdD32ZHT9E8CpI/39MyDMpQYFb9w5pjw5idCBv7s8=; b=FcK7f0f7gUwOmHp6fWm+8aZ1Rz/YZ7/zrQ+WAfalQ5UzS/zNXSdVokPgIiM9oEHoYz jS1jy68h1beQ6fxvLqpB487QWhxIJNYvDQSGB2H/t19xXx8qEptmMBTeY4aHK/Xm/C6Y pyxofHoVMaiVCio9+cRrPGPX5d9kteHLbwj6QWkN1KEq3xwdU1o/Ba2bp4zkevdCnFsR AGhh/lL6/Qj6bLdVpgTqZ5Oj+Vl5WX7allnVO2mW6VlDjwaZvtppvCCLs778OeM+/OEN ezS2bAhPGWxaYhLiOdp3scJQu8PQrY9JASFm02iLLRsrgJA88aTJRrQGd/8rzCFrLNlG xZmg== X-Gm-Message-State: ALoCoQnzM3FHs5XcqmbVkHnmcu+HW7aLgWKIiZllT/aUW3hDpkb0obvljQ1KmW6DSPgKuHTrb6k3 X-Received: by 10.66.141.135 with SMTP id ro7mr4160601pab.28.1400138517472; Thu, 15 May 2014 00:21:57 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.97.200 with SMTP id m66ls88417qge.83.gmail; Thu, 15 May 2014 00:21:57 -0700 (PDT) X-Received: by 10.58.178.70 with SMTP id cw6mr4450955vec.24.1400138517316; Thu, 15 May 2014 00:21:57 -0700 (PDT) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by mx.google.com with ESMTPS id gu9si771715vdc.178.2014.05.15.00.21.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 00:21:57 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.171 as permitted sender) client-ip=209.85.128.171; Received: by mail-ve0-f171.google.com with SMTP id oz11so770670veb.2 for ; Thu, 15 May 2014 00:21:57 -0700 (PDT) X-Received: by 10.221.40.193 with SMTP id tr1mr286843vcb.31.1400138517207; Thu, 15 May 2014 00:21:57 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp299961vcb; Thu, 15 May 2014 00:21:56 -0700 (PDT) X-Received: by 10.68.170.131 with SMTP id am3mr10063052pbc.97.1400138516445; Thu, 15 May 2014 00:21:56 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id vr7si4452527pab.117.2014.05.15.00.21.55; Thu, 15 May 2014 00:21:55 -0700 (PDT) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754531AbaEOHVs (ORCPT + 27 others); Thu, 15 May 2014 03:21:48 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:43735 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753995AbaEOHVq (ORCPT ); Thu, 15 May 2014 03:21:46 -0400 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 CC: , , Wang Nan , Geng Hui 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: wangnan0@huawei.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.171 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , 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"