From: Wang Nan <wangnan0@huawei.com>
To: Russell King <linux@arm.linux.org.uk>,
Simon Horman <horms@verge.net.au>,
Will Deacon <will.deacon@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <kexec@lists.infradead.org>,
Geng Hui <hui.geng@huawei.com>, Wang Nan <wangnan0@huawei.com>
Subject: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
Date: Wed, 28 May 2014 16:44:28 +0800 [thread overview]
Message-ID: <1401266668-34365-1-git-send-email-wangnan0@huawei.com> (raw)
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 <wangnan0@huawei.com>
---
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
--
1.8.4
next reply other threads:[~2014-05-28 8:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 8:44 Wang Nan [this message]
2014-05-29 4:54 ` [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform AKASHI Takahiro
2014-05-29 8:01 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1401266668-34365-1-git-send-email-wangnan0@huawei.com \
--to=wangnan0@huawei.com \
--cc=horms@verge.net.au \
--cc=hui.geng@huawei.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).