* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
@ 2014-05-19 1:54 Wang Nan
2014-05-19 16:09 ` Will Deacon
0 siblings, 1 reply; 6+ messages in thread
From: Wang Nan @ 2014-05-19 1:54 UTC (permalink / raw)
To: linux-arm-kernel
When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
the second kernel ioremap first kernel's memory if the address falls
into second kernel section. This limitation requires the second kernel
occupies a full section, and elfcorehdr must resides in another section.
This patch makes crash dump kernel use strict pfn_valid, removes such
limitation.
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.
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Cc: Geng Hui <hui.geng@huawei.com>
---
I have sent this patch once, but get no response. Resend with commit
message update.
---
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"
--
1.8.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
2014-05-19 1:54 [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid Wang Nan
@ 2014-05-19 16:09 ` Will Deacon
2014-05-20 3:22 ` Wang Nan
0 siblings, 1 reply; 6+ messages in thread
From: Will Deacon @ 2014-05-19 16:09 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
> the second kernel ioremap first kernel's memory if the address falls
> into second kernel section. This limitation requires the second kernel
> occupies a full section, and elfcorehdr must resides in another section.
>
> This patch makes crash dump kernel use strict pfn_valid, removes such
> limitation.
>
> 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.
So isn't the issue here that you're passing an incorrect mem= parameter
to the crash kernel?
Will
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
2014-05-19 16:09 ` Will Deacon
@ 2014-05-20 3:22 ` Wang Nan
2014-05-22 1:53 ` Wang Nan
2014-05-29 4:39 ` AKASHI Takahiro
0 siblings, 2 replies; 6+ messages in thread
From: Wang Nan @ 2014-05-20 3:22 UTC (permalink / raw)
To: linux-arm-kernel
On 2014/5/20 0:09, Will Deacon wrote:
> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
>> the second kernel ioremap first kernel's memory if the address falls
>> into second kernel section. This limitation requires the second kernel
>> occupies a full section, and elfcorehdr must resides in another section.
>>
>> This patch makes crash dump kernel use strict pfn_valid, removes such
>> limitation.
>>
>> 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.
>
> So isn't the issue here that you're passing an incorrect mem= parameter
> to the crash kernel?
>
mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size
of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect
crashkernel= parameter?
I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM
enabled, and show how *impractical* the 'correct' crashkernel will be.
Use realview board for example.
Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
This is because zImage determine final kernel address by (pc & 0xf8000000). If,
for example, set crashkernel=64M at 0x29000000, then the second kernel itself
overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
Limitation 2: crash kernel must resides in different section with the first kernel.
This is because the second kernel use ioremap for accessing first kernel's memory,
and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved
for the secton kernel. On realview, which is 256MiB.
Limitation 3: the last 1MiB of reserved memory must be ioremappable.
This is because the second kernel depeneds kexec-tools passing an elfheader as
'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools
simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
the header be put in another section.
In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
set this parameter, crash kernel is still unusable because:
crashkernel reservation failed - memory is in use (0x20000000)
> Will
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
2014-05-20 3:22 ` Wang Nan
@ 2014-05-22 1:53 ` Wang Nan
2014-05-29 4:39 ` AKASHI Takahiro
1 sibling, 0 replies; 6+ messages in thread
From: Wang Nan @ 2014-05-22 1:53 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will,
What's your opinion about my explanation?
Thanks!
On 2014/5/20 11:22, Wang Nan wrote:
> On 2014/5/20 0:09, Will Deacon wrote:
>> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
>>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
>>> the second kernel ioremap first kernel's memory if the address falls
>>> into second kernel section. This limitation requires the second kernel
>>> occupies a full section, and elfcorehdr must resides in another section.
>>>
>>> This patch makes crash dump kernel use strict pfn_valid, removes such
>>> limitation.
>>>
>>> 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.
>>
>> So isn't the issue here that you're passing an incorrect mem= parameter
>> to the crash kernel?
>>
>
> mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size
> of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect
> crashkernel= parameter?
>
> I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM
> enabled, and show how *impractical* the 'correct' crashkernel will be.
>
> Use realview board for example.
>
> Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
>
> This is because zImage determine final kernel address by (pc & 0xf8000000). If,
> for example, set crashkernel=64M at 0x29000000, then the second kernel itself
> overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
>
> Limitation 2: crash kernel must resides in different section with the first kernel.
>
> This is because the second kernel use ioremap for accessing first kernel's memory,
> and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved
> for the secton kernel. On realview, which is 256MiB.
>
> Limitation 3: the last 1MiB of reserved memory must be ioremappable.
>
> This is because the second kernel depeneds kexec-tools passing an elfheader as
> 'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools
> simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
> the header be put in another section.
>
> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
> However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
> set this parameter, crash kernel is still unusable because:
>
> crashkernel reservation failed - memory is in use (0x20000000)
>
>> Will
>>
>
>
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
2014-05-20 3:22 ` Wang Nan
2014-05-22 1:53 ` Wang Nan
@ 2014-05-29 4:39 ` AKASHI Takahiro
2014-05-29 10:09 ` Wang Nan
1 sibling, 1 reply; 6+ messages in thread
From: AKASHI Takahiro @ 2014-05-29 4:39 UTC (permalink / raw)
To: linux-arm-kernel
Wang, Will
I'm now working on kdump support for arm64 on top of Geoff's kexec patch.
On 05/20/2014 12:22 PM, Wang Nan wrote:
> On 2014/5/20 0:09, Will Deacon wrote:
>> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
>>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
>>> the second kernel ioremap first kernel's memory if the address falls
>>> into second kernel section. This limitation requires the second kernel
>>> occupies a full section, and elfcorehdr must resides in another section.
>>>
>>> This patch makes crash dump kernel use strict pfn_valid, removes such
>>> limitation.
>>>
>>> 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.
>>
>> So isn't the issue here that you're passing an incorrect mem= parameter
>> to the crash kernel?
>>
>
> mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size
> of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect
> crashkernel= parameter?
Just FYI, kexec-tools doesn't seem to be implemented in proper way to support device-tree.
Once device-tree is handled correctly, we don't need to pass "mem=" parameter.
(Of course, only on machines that support device-tree.)
> I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM
> enabled, and show how *impractical* the 'correct' crashkernel will be.
>
> Use realview board for example.
>
> Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
>
> This is because zImage determine final kernel address by (pc & 0xf8000000). If,
> for example, set crashkernel=64M at 0x29000000, then the second kernel itself
> overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
>
> Limitation 2: crash kernel must resides in different section with the first kernel.
>
> This is because the second kernel use ioremap for accessing first kernel's memory,
> and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved
> for the secton kernel. On realview, which is 256MiB.
>
> Limitation 3: the last 1MiB of reserved memory must be ioremappable.
>
> This is because the second kernel depeneds kexec-tools passing an elfheader as
> 'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools
> simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
> the header be put in another section.
We can avoid "Limitation 3" just by implementing arm's own elfcorehdr_read() with memcpy().
I can submit a patch, but can't test it for now.
-Takahiro AKASHI
> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
> However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
> set this parameter, crash kernel is still unusable because:
>
> crashkernel reservation failed - memory is in use (0x20000000)
>
>> Will
>>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid
2014-05-29 4:39 ` AKASHI Takahiro
@ 2014-05-29 10:09 ` Wang Nan
0 siblings, 0 replies; 6+ messages in thread
From: Wang Nan @ 2014-05-29 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On 2014/5/29 12:39, AKASHI Takahiro wrote:
> Wang, Will
>
> I'm now working on kdump support for arm64 on top of Geoff's kexec patch.
>
> On 05/20/2014 12:22 PM, Wang Nan wrote:
>> On 2014/5/20 0:09, Will Deacon wrote:
>>> On Mon, May 19, 2014 at 02:54:03AM +0100, Wang Nan wrote:
>>>> When SPARSEMEM and CRASH_DUMP both selected, simple pfn_valid prevents
>>>> the second kernel ioremap first kernel's memory if the address falls
>>>> into second kernel section. This limitation requires the second kernel
>>>> occupies a full section, and elfcorehdr must resides in another section.
>>>>
>>>> This patch makes crash dump kernel use strict pfn_valid, removes such
>>>> limitation.
>>>>
>>>> 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.
>>>
>>> So isn't the issue here that you're passing an incorrect mem= parameter
>>> to the crash kernel?
>>>
>>
>> mem= parameter is generated by kexec-tools according to /proc/iomem, it is the size
>> of reserved memory minus 1MiB. So I think what you mean is I passing an incorrect
>> crashkernel= parameter?
>
> Just FYI, kexec-tools doesn't seem to be implemented in proper way to support device-tree.
> Once device-tree is handled correctly, we don't need to pass "mem=" parameter.
> (Of course, only on machines that support device-tree.)
>
>> I'll explain limitations on crash kernel reserved memory in the case of SPARSEMEM
>> enabled, and show how *impractical* the 'correct' crashkernel will be.
>>
>> Use realview board for example.
>>
>> Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
>>
>> This is because zImage determine final kernel address by (pc & 0xf8000000). If,
>> for example, set crashkernel=64M at 0x29000000, then the second kernel itself
>> overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
>>
>> Limitation 2: crash kernel must resides in different section with the first kernel.
>>
>> This is because the second kernel use ioremap for accessing first kernel's memory,
>> and arm prevent a valid pfn be ioremapped. Which means a whole section must be reserved
>> for the secton kernel. On realview, which is 256MiB.
>>
>> Limitation 3: the last 1MiB of reserved memory must be ioremappable.
>>
>> This is because the second kernel depeneds kexec-tools passing an elfheader as
>> 'elfcorehdr' to instructs it generating /proc/vmcore. See fs/proc/vmcore.c. Kexec-tools
>> simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
>> the header be put in another section.
>
> We can avoid "Limitation 3" just by implementing arm's own elfcorehdr_read() with memcpy().
> I can submit a patch, but can't test it for now.
>
> -Takahiro AKASHI
>
However you still need pfn_valid to check whether elfcorehdr resides in a valid area.
Furthermore, simply replacing ioremap to memcpy seems breaks things. Configurations work
before replacement will fail. Finally you will find you still need strict pfn_valid to
check whether to use ioremap or use memcpy.
>
>> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
>> However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
>> set this parameter, crash kernel is still unusable because:
>>
>> crashkernel reservation failed - memory is in use (0x20000000)
>>
>>> Will
>>>
>>
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-29 10:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-19 1:54 [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid Wang Nan
2014-05-19 16:09 ` Will Deacon
2014-05-20 3:22 ` Wang Nan
2014-05-22 1:53 ` Wang Nan
2014-05-29 4:39 ` AKASHI Takahiro
2014-05-29 10:09 ` Wang Nan
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).