From: Wang Nan <wangnan0@huawei.com>
To: Wang Nan <wangnan0@huawei.com>,
Russell King <linux@arm.linux.org.uk>,
Will Deacon <will.deacon@arm.com>,
Simon Horman <horms@verge.net.au>,
Mika Westerberg <ext-mika.1.westerberg@nokia.com>
Cc: "kexec@lists.infradead.org" <kexec@lists.infradead.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Geng Hui <hui.geng@huawei.com>
Subject: Re: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid
Date: Thu, 15 May 2014 15:30:58 +0800 [thread overview]
Message-ID: <53746D32.4000708@huawei.com> (raw)
In-Reply-To: <1400138070-24046-1-git-send-email-wangnan0@huawei.com>
Add kexec@lists.infradead.org to cc list.
On 2014/5/15 15:14, Wang Nan wrote:
> 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 <wangnan0@huawei.com>
> Cc: Geng Hui <hui.geng@huawei.com>
> Cc: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> Cc: Simon Horman <horms@verge.net.au>
> ---
> 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"
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: wangnan0@huawei.com (Wang Nan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid
Date: Thu, 15 May 2014 15:30:58 +0800 [thread overview]
Message-ID: <53746D32.4000708@huawei.com> (raw)
In-Reply-To: <1400138070-24046-1-git-send-email-wangnan0@huawei.com>
Add kexec at lists.infradead.org to cc list.
On 2014/5/15 15:14, Wang Nan wrote:
> 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 at 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 at 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 <wangnan0@huawei.com>
> Cc: Geng Hui <hui.geng@huawei.com>
> Cc: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> Cc: Simon Horman <horms@verge.net.au>
> ---
> 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"
>
WARNING: multiple messages have this Message-ID (diff)
From: Wang Nan <wangnan0@huawei.com>
To: Wang Nan <wangnan0@huawei.com>,
Russell King <linux@arm.linux.org.uk>,
Will Deacon <will.deacon@arm.com>,
Simon Horman <horms@verge.net.au>,
"Mika Westerberg" <ext-mika.1.westerberg@nokia.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, Geng Hui <hui.geng@huawei.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid
Date: Thu, 15 May 2014 15:30:58 +0800 [thread overview]
Message-ID: <53746D32.4000708@huawei.com> (raw)
In-Reply-To: <1400138070-24046-1-git-send-email-wangnan0@huawei.com>
Add kexec@lists.infradead.org to cc list.
On 2014/5/15 15:14, Wang Nan wrote:
> 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 <wangnan0@huawei.com>
> Cc: Geng Hui <hui.geng@huawei.com>
> Cc: Mika Westerberg <ext-mika.1.westerberg@nokia.com>
> Cc: Simon Horman <horms@verge.net.au>
> ---
> 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"
>
next prev parent reply other threads:[~2014-05-15 7:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 7:14 [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid Wang Nan
2014-05-15 7:14 ` Wang Nan
2014-05-15 7:30 ` Wang Nan [this message]
2014-05-15 7:30 ` Wang Nan
2014-05-15 7:30 ` Wang Nan
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=53746D32.4000708@huawei.com \
--to=wangnan0@huawei.com \
--cc=ext-mika.1.westerberg@nokia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.