* [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-28 8:44 ` Wang Nan
0 siblings, 0 replies; 9+ messages in thread
From: Wang Nan @ 2014-05-28 8:44 UTC (permalink / raw)
To: Russell King, Simon Horman, Will Deacon
Cc: linux-arm-kernel, linux-kernel, kexec, Geng Hui, Wang Nan
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-28 8:44 ` Wang Nan
0 siblings, 0 replies; 9+ messages in thread
From: Wang Nan @ 2014-05-28 8:44 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-28 8:44 ` Wang Nan
0 siblings, 0 replies; 9+ messages in thread
From: Wang Nan @ 2014-05-28 8:44 UTC (permalink / raw)
To: Russell King, Simon Horman, Will Deacon
Cc: Wang Nan, kexec, linux-kernel, linux-arm-kernel, Geng Hui
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
2014-05-28 8:44 ` Wang Nan
(?)
@ 2014-05-29 4:54 ` AKASHI Takahiro
-1 siblings, 0 replies; 9+ messages in thread
From: AKASHI Takahiro @ 2014-05-29 4:54 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Wang Nan, Russell King, Simon Horman, kexec, linux-kernel,
linux-arm-kernel, Geng Hui
Catalin, Will
Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
Looking at arm64/Kconfig,
config ARCH_HAS_HOLES_MEMORYMODEL
def_bool y if SPARSEMEM
...
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
is this intentional?
-Takahiro AKASHI
On 05/28/2014 05:44 PM, Wang Nan wrote:
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-29 4:54 ` AKASHI Takahiro
0 siblings, 0 replies; 9+ messages in thread
From: AKASHI Takahiro @ 2014-05-29 4:54 UTC (permalink / raw)
To: linux-arm-kernel
Catalin, Will
Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
Looking at arm64/Kconfig,
config ARCH_HAS_HOLES_MEMORYMODEL
def_bool y if SPARSEMEM
...
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
is this intentional?
-Takahiro AKASHI
On 05/28/2014 05:44 PM, Wang Nan wrote:
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-29 4:54 ` AKASHI Takahiro
0 siblings, 0 replies; 9+ messages in thread
From: AKASHI Takahiro @ 2014-05-29 4:54 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Wang Nan, Russell King, kexec, linux-kernel, Geng Hui,
Simon Horman, linux-arm-kernel
Catalin, Will
Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
Looking at arm64/Kconfig,
config ARCH_HAS_HOLES_MEMORYMODEL
def_bool y if SPARSEMEM
...
config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
is this intentional?
-Takahiro AKASHI
On 05/28/2014 05:44 PM, Wang Nan wrote:
> 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
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
2014-05-29 4:54 ` AKASHI Takahiro
(?)
@ 2014-05-29 8:01 ` Will Deacon
-1 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2014-05-29 8:01 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: Catalin Marinas, Wang Nan, Russell King, Simon Horman, kexec,
linux-kernel, linux-arm-kernel, Geng Hui
On Thu, May 29, 2014 at 05:54:02AM +0100, AKASHI Takahiro wrote:
> Catalin, Will
>
> Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
> Looking at arm64/Kconfig,
> config ARCH_HAS_HOLES_MEMORYMODEL
> def_bool y if SPARSEMEM
> ...
> config HAVE_ARCH_PFN_VALID
> def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>
> is this intentional?
Looks like an artifact of the way we constructed those option, so yes, we
could just make that a def_bool y if you like.
Will
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-29 8:01 ` Will Deacon
0 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2014-05-29 8:01 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 29, 2014 at 05:54:02AM +0100, AKASHI Takahiro wrote:
> Catalin, Will
>
> Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
> Looking at arm64/Kconfig,
> config ARCH_HAS_HOLES_MEMORYMODEL
> def_bool y if SPARSEMEM
> ...
> config HAVE_ARCH_PFN_VALID
> def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>
> is this intentional?
Looks like an artifact of the way we constructed those option, so yes, we
could just make that a def_bool y if you like.
Will
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform
@ 2014-05-29 8:01 ` Will Deacon
0 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2014-05-29 8:01 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: Wang Nan, Russell King, Catalin Marinas, kexec, linux-kernel,
Geng Hui, Simon Horman, linux-arm-kernel
On Thu, May 29, 2014 at 05:54:02AM +0100, AKASHI Takahiro wrote:
> Catalin, Will
>
> Can we assume that HAVE_ARCH_PFN_VALID is alway yes on arm64?
> Looking at arm64/Kconfig,
> config ARCH_HAS_HOLES_MEMORYMODEL
> def_bool y if SPARSEMEM
> ...
> config HAVE_ARCH_PFN_VALID
> def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
>
> is this intentional?
Looks like an artifact of the way we constructed those option, so yes, we
could just make that a def_bool y if you like.
Will
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-29 8:03 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-28 8:44 [PATCH RESEND] ARM: kdump: 2nd kernel should use strict pfn_valid in SPARSEMEM platform Wang Nan
2014-05-28 8:44 ` Wang Nan
2014-05-28 8:44 ` Wang Nan
2014-05-29 4:54 ` AKASHI Takahiro
2014-05-29 4:54 ` AKASHI Takahiro
2014-05-29 4:54 ` AKASHI Takahiro
2014-05-29 8:01 ` Will Deacon
2014-05-29 8:01 ` Will Deacon
2014-05-29 8:01 ` Will Deacon
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.