From: neidhard.kim@lge.com (Kim, Jong-Sung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Fri, 8 Jun 2012 22:58:50 +0900 [thread overview]
Message-ID: <025701cd457e$d5065410$7f12fc30$@lge.com> (raw)
In-Reply-To: <1338880312-17561-1-git-send-email-minchan@kernel.org>
> From: Minchan Kim [mailto:minchan at kernel.org]
> Sent: Tuesday, June 05, 2012 4:12 PM
>
> If we do arm_memblock_steal with a page which is not aligned with section
> size, panic can happen during boot by page fault in map_lowmem.
>
> Detail:
>
> 1) mdesc->reserve can steal a page which is allocated at 0x1ffff000 by
> memblock
> which prefers tail pages of regions.
> 2) map_lowmem maps 0x00000000 - 0x1fe00000
> 3) map_lowmem try to map 0x1fe00000 but it's not aligned by section due to
1.
> 4) calling alloc_init_pte allocates a new page for new pte by
memblock_alloc
> 5) allocated memory for pte is 0x1fffe000 -> it's not mapped yet.
> 6) memset(ptr, 0, sz) in early_alloc_aligned got PANICed!
May I suggest another simple approach? The first continuous couples of
sections are always safely section-mapped inside alloc_init_section funtion.
So, by limiting memblock_alloc to the end of the first continuous couples of
sections at the start of map_lowmem, map_lowmem can safely memblock_alloc &
memset even if we have one or more section-unaligned memory regions. The
limit can be extended back to arm_lowmem_limit after the map_lowmem is done.
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e5dad60..edf1e2d 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1094,6 +1094,11 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
+ phys_addr_t pmd_map_end;
+
+ pmd_map_end = (memblock.memory.regions[0].base +
+ memblock.memory.regions[0].size) & PMD_MASK;
+ memblock_set_current_limit(pmd_map_end);
/* Map all the lowmem memory banks. */
for_each_memblock(memory, reg) {
@@ -1113,6 +1118,8 @@ static void __init map_lowmem(void)
create_mapping(&map);
}
+
+ memblock_set_current_limit(arm_lowmem_limit);
}
/*
@@ -1123,8 +1130,6 @@ void __init paging_init(struct machine_desc *mdesc)
{
void *zero_page;
- memblock_set_current_limit(arm_lowmem_limit);
-
build_mem_type_table();
prepare_page_table();
map_lowmem();
WARNING: multiple messages have this Message-ID (diff)
From: "Kim, Jong-Sung" <neidhard.kim@lge.com>
To: 'Minchan Kim' <minchan@kernel.org>,
'Russell King' <linux@arm.linux.org.uk>
Cc: 'Nicolas Pitre' <nico@linaro.org>,
'Catalin Marinas' <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, 'Chanho Min' <chanho.min@lge.com>,
linux-mm@kvack.org
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Fri, 8 Jun 2012 22:58:50 +0900 [thread overview]
Message-ID: <025701cd457e$d5065410$7f12fc30$@lge.com> (raw)
In-Reply-To: <1338880312-17561-1-git-send-email-minchan@kernel.org>
> From: Minchan Kim [mailto:minchan@kernel.org]
> Sent: Tuesday, June 05, 2012 4:12 PM
>
> If we do arm_memblock_steal with a page which is not aligned with section
> size, panic can happen during boot by page fault in map_lowmem.
>
> Detail:
>
> 1) mdesc->reserve can steal a page which is allocated at 0x1ffff000 by
> memblock
> which prefers tail pages of regions.
> 2) map_lowmem maps 0x00000000 - 0x1fe00000
> 3) map_lowmem try to map 0x1fe00000 but it's not aligned by section due to
1.
> 4) calling alloc_init_pte allocates a new page for new pte by
memblock_alloc
> 5) allocated memory for pte is 0x1fffe000 -> it's not mapped yet.
> 6) memset(ptr, 0, sz) in early_alloc_aligned got PANICed!
May I suggest another simple approach? The first continuous couples of
sections are always safely section-mapped inside alloc_init_section funtion.
So, by limiting memblock_alloc to the end of the first continuous couples of
sections at the start of map_lowmem, map_lowmem can safely memblock_alloc &
memset even if we have one or more section-unaligned memory regions. The
limit can be extended back to arm_lowmem_limit after the map_lowmem is done.
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e5dad60..edf1e2d 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1094,6 +1094,11 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
+ phys_addr_t pmd_map_end;
+
+ pmd_map_end = (memblock.memory.regions[0].base +
+ memblock.memory.regions[0].size) & PMD_MASK;
+ memblock_set_current_limit(pmd_map_end);
/* Map all the lowmem memory banks. */
for_each_memblock(memory, reg) {
@@ -1113,6 +1118,8 @@ static void __init map_lowmem(void)
create_mapping(&map);
}
+
+ memblock_set_current_limit(arm_lowmem_limit);
}
/*
@@ -1123,8 +1130,6 @@ void __init paging_init(struct machine_desc *mdesc)
{
void *zero_page;
- memblock_set_current_limit(arm_lowmem_limit);
-
build_mem_type_table();
prepare_page_table();
map_lowmem();
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: "Kim, Jong-Sung" <neidhard.kim@lge.com>
To: "'Minchan Kim'" <minchan@kernel.org>,
"'Russell King'" <linux@arm.linux.org.uk>
Cc: "'Nicolas Pitre'" <nico@linaro.org>,
"'Catalin Marinas'" <catalin.marinas@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
"'Chanho Min'" <chanho.min@lge.com>, <linux-mm@kvack.org>
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Fri, 8 Jun 2012 22:58:50 +0900 [thread overview]
Message-ID: <025701cd457e$d5065410$7f12fc30$@lge.com> (raw)
In-Reply-To: <1338880312-17561-1-git-send-email-minchan@kernel.org>
> From: Minchan Kim [mailto:minchan@kernel.org]
> Sent: Tuesday, June 05, 2012 4:12 PM
>
> If we do arm_memblock_steal with a page which is not aligned with section
> size, panic can happen during boot by page fault in map_lowmem.
>
> Detail:
>
> 1) mdesc->reserve can steal a page which is allocated at 0x1ffff000 by
> memblock
> which prefers tail pages of regions.
> 2) map_lowmem maps 0x00000000 - 0x1fe00000
> 3) map_lowmem try to map 0x1fe00000 but it's not aligned by section due to
1.
> 4) calling alloc_init_pte allocates a new page for new pte by
memblock_alloc
> 5) allocated memory for pte is 0x1fffe000 -> it's not mapped yet.
> 6) memset(ptr, 0, sz) in early_alloc_aligned got PANICed!
May I suggest another simple approach? The first continuous couples of
sections are always safely section-mapped inside alloc_init_section funtion.
So, by limiting memblock_alloc to the end of the first continuous couples of
sections at the start of map_lowmem, map_lowmem can safely memblock_alloc &
memset even if we have one or more section-unaligned memory regions. The
limit can be extended back to arm_lowmem_limit after the map_lowmem is done.
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e5dad60..edf1e2d 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1094,6 +1094,11 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
+ phys_addr_t pmd_map_end;
+
+ pmd_map_end = (memblock.memory.regions[0].base +
+ memblock.memory.regions[0].size) & PMD_MASK;
+ memblock_set_current_limit(pmd_map_end);
/* Map all the lowmem memory banks. */
for_each_memblock(memory, reg) {
@@ -1113,6 +1118,8 @@ static void __init map_lowmem(void)
create_mapping(&map);
}
+
+ memblock_set_current_limit(arm_lowmem_limit);
}
/*
@@ -1123,8 +1130,6 @@ void __init paging_init(struct machine_desc *mdesc)
{
void *zero_page;
- memblock_set_current_limit(arm_lowmem_limit);
-
build_mem_type_table();
prepare_page_table();
map_lowmem();
next prev parent reply other threads:[~2012-06-08 13:58 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 7:11 [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc Minchan Kim
2012-06-05 7:11 ` Minchan Kim
2012-06-05 7:11 ` Minchan Kim
2012-06-08 13:58 ` Kim, Jong-Sung [this message]
2012-06-08 13:58 ` Kim, Jong-Sung
2012-06-08 13:58 ` Kim, Jong-Sung
2012-06-27 16:02 ` Dave Martin
2012-06-27 16:02 ` Dave Martin
2012-06-27 16:02 ` Dave Martin
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-28 6:08 ` Kim, Jong-Sung
2012-06-28 6:08 ` Kim, Jong-Sung
2012-06-28 6:08 ` Kim, Jong-Sung
2012-06-19 8:38 ` Minchan Kim
2012-06-19 8:38 ` Minchan Kim
2012-06-19 8:38 ` Minchan Kim
2012-06-27 16:12 ` Dave Martin
2012-06-27 16:12 ` Dave Martin
2012-06-27 16:12 ` Dave Martin
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:46 ` Minchan Kim
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 17:50 ` Nicolas Pitre
2012-06-28 17:50 ` Nicolas Pitre
2012-06-28 17:50 ` Nicolas Pitre
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='025701cd457e$d5065410$7f12fc30$@lge.com' \
--to=neidhard.kim@lge.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.