ARM: mm: Fix alloc_init_section bug on LPAE
RFC PATCH 1/1 ARM: mm: Fix alloc_init_section bug on LPAE
When using LPAE the call to alloc_init_pte is passed then end address for the entire 1st level page table region, and the code unluckily ends up going over the bounds of the single allocated PTE, which is sad.
This caused LPAE boot on omap5 to crash.
There may be some hidden mystery in the boot code that I'm unaware of or it may be assumed that all mappings are always mappable as sections on LPAE and therefore omap5 just does something bad, in which case this patch isn't the right fix, but I'd be happy to be told the reason.
--- arch/arm/mm/mmu.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)
arch/arm/mm/mmu.c +7 -5
@@ -603,11 +603,13 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,flush_pmd_entry (p); }else { -/* -* No need to loop; pte's aren't interested in the -* individual L1 entries. -*/ -alloc_init_pte (pmd, addr, end,__phys_to_pfn (phys), type); +unsigned long next; + +do { + next =pmd_addr_end (addr, end); +alloc_init_pte (pmd, addr, next,__phys_to_pfn (phys), type); + phys += next - addr; + }while (pmd++, addr = next, addr != end); } }
Signature · 1 line
1.7.9.5
RFC PATCH 1/1 ARM: mm: Fix alloc_init_section bug on LPAE
Hi Christoffer,
Quoted 11 lines · Christoffer Dall
When using LPAE the call to
alloc_init_pteis passed then end address for the entire 1st level page table region, and the code unluckily ends up going over the bounds of the single allocated PTE, which is sad.This caused LPAE boot on omap5 to crash.
There may be some hidden mystery in the boot code that I'm unaware of or it may be assumed that all mappings are always mappable as sections on LPAE and therefore omap5 just does something bad, in which case this patch isn't the right fix, but I'd be happy to be told the reason.
Quoted 4 lines
Cc Tony Lindgren <[email protected]>Cc Jeremy C. Andrus <[email protected]>Signed-off-by Christoffer Dall <[email protected]>---
I was about to reply on the LPAE boot issue you mentioned in other email. We have seen couple of issues with LPAE on OMAP5 and sent the fixes.
[1] ARM: LPAE: Fix alloc_init_section to flush all the pmd entries
[2] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses
Both needs ack from Catalin and RMK's ok to get into the patch system.
Can you please check if they work for you ? I expect the [1] should make your board boot on OMAP5.
Regards
Santosh
RFC PATCH 1/1 ARM: mm: Fix alloc_init_section bug on LPAE
Quoted 26 lines · Santosh Shilimkar
Hi Christoffer,
Quoted 12 lines · Christoffer Dall
When using LPAE the call to
alloc_init_pteis passed then end address for the entire 1st level page table region, and the code unluckily ends up going over the bounds of the single allocated PTE, which is sad.This caused LPAE boot on omap5 to crash.
There may be some hidden mystery in the boot code that I'm unaware of or it may be assumed that all mappings are always mappable as sections on LPAE and therefore omap5 just does something bad, in which case this patch isn't the right fix, but I'd be happy to be told the reason.
Quoted 4 lines
Cc Tony Lindgren <[email protected]>Cc Jeremy C. Andrus <[email protected]>Signed-off-by Christoffer Dall <[email protected]>---
I was about to reply on the LPAE boot issue you mentioned in other email. We have seen couple of issues with LPAE on OMAP5 and sent the fixes.
Quoted 8 lines
[1] ARM: LPAE: Fix
alloc_init_sectionto flush all the pmd entries
[2] ARM: LPAE: Fix mapping inalloc_init_ptefor unaligned addressesBoth needs ack from Catalin and RMK's ok to get into the patch system.
Can you please check if they work for you ? I expect the [1] should make your board boot on OMAP5.
yeah, that patch had the same effect as my patch (with the extra waste of memory for the ptes as Russell pointed out).
My googling of fixes for this completely failed somehow.
Thanks for pointing it out.
-Christoffer
RFC PATCH 1/1 ARM: mm: Fix alloc_init_section bug on LPAE
In reply to Christoffer DallQuoted 28 lines · Christoffer Dall
When using LPAE the call to
alloc_init_pteis passed then end address for the entire 1st level page table region, and the code unluckily ends up going over the bounds of the single allocated PTE, which is sad.This caused LPAE boot on omap5 to crash.
There may be some hidden mystery in the boot code that I'm unaware of or it may be assumed that all mappings are always mappable as sections on LPAE and therefore omap5 just does something bad, in which case this patch isn't the right fix, but I'd be happy to be told the reason.
Cc Tony Lindgren <[email protected]>Cc Jeremy C. Andrus <[email protected]>Signed-off-by Christoffer Dall <[email protected]>--- arch/arm/mm/mmu.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-)arch/arm/mm/mmu.c +0
-2@@ -603,11 +603,13 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,flush_pmd_entry (p); }else { -/* -* No need to loop; pte's aren't interested in the
arch/arm/mm/mmu.c static void __init alloc_init_section(pud_t *pud, unsigned long addr, · line 612
Quoted 10 lines
arch/arm/mm/mmu.c +7
-3-* individual L1 entries. -*/ -alloc_init_pte (pmd, addr, end,__phys_to_pfn (phys), type); +unsigned long next; + +do { + next =pmd_addr_end (addr, end); +alloc_init_pte (pmd, addr, next,__phys_to_pfn (phys), type); + phys += next - addr; + }while (pmd++, addr = next, addr != end);
I now noticed your patch (I'm a bit behind with the list). It looks to me like it should work since next == end with the classic MMU, so we only go through the loop once.
Signature · 1 line
Catalin