The purpose of this serie is to:
- use BATs with STRICT_KERNEL_RWX on book3s (See patch 12 for details.)
- use LTLBs with STRICT_KERNEL_RWX on 8xx (See patch 14 for a few details.)
v2:
- Fix patch 2 (was patch 3 in v1) based on feedback from Jonathan.
- Added support for 8xx with LTLBs.
- Added systematic population of pagetables for Abatron BDI.
Christophe Leroy (15):
powerpc/mm/32: add base address to mmu_mapin_ram()
powerpc/mm/32s: rework mmu_mapin_ram()
powerpc/mm/32s: use generic mmu_mapin_ram() for all blocks.
powerpc/32: always populate page tables for Abatron BDI.
powerpc/wii: remove wii_mmu_mapin_mem2()
powerpc/mm/32s: use _PAGE_EXEC in setbat()
powerpc/mm/32s: add setibat() clearibat() and update_bats()
powerpc/32: add helper to write into segment registers
powerpc/mmu: add is_strict_kernel_rwx() helper
powerpc/kconfig: define PAGE_SHIFT inside Kconfig
powerpc/kconfig: define CONFIG_DATA_SHIFT and CONFIG_ETEXT_SHIFT
powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX
powerpc/kconfig: make _etext and data areas alignment configurable on
Book3s 32
powerpc/8xx: don't disable large TLBs with CONFIG_STRICT_KERNEL_RWX
powerpc/kconfig: make _etext and data areas alignment configurable on
8xx
arch/powerpc/Kconfig | 60 +++++++++
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 +
arch/powerpc/include/asm/book3s/32/pgtable.h | 11 ++
arch/powerpc/include/asm/mmu.h | 11 ++
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 3 +-
arch/powerpc/include/asm/page.h | 13 +-
arch/powerpc/include/asm/reg.h | 5 +
arch/powerpc/kernel/head_32.S | 35 +++++
arch/powerpc/kernel/head_8xx.S | 33 ++++-
arch/powerpc/kernel/vmlinux.lds.S | 9 +-
arch/powerpc/mm/40x_mmu.c | 2 +-
arch/powerpc/mm/44x_mmu.c | 2 +-
arch/powerpc/mm/8xx_mmu.c | 33 ++++-
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/init_32.c | 6 +-
arch/powerpc/mm/mmu_decl.h | 10 +-
arch/powerpc/mm/pgtable_32.c | 38 +++---
arch/powerpc/mm/ppc_mmu_32.c | 178 ++++++++++++++++++++++----
arch/powerpc/platforms/embedded6xx/wii.c | 24 ----
19 files changed, 378 insertions(+), 99 deletions(-)
--
2.13.3
At the time being, mmu_mapin_ram() always maps RAM from the beginning.
But some platforms like the WII have to map a second block of RAM.
This patch adds to mmu_mapin_ram() the base address of the block.
At the moment, only base address 0 is supported.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/40x_mmu.c | 2 +-
arch/powerpc/mm/44x_mmu.c | 2 +-
arch/powerpc/mm/8xx_mmu.c | 2 +-
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 2 +-
arch/powerpc/mm/pgtable_32.c | 6 +++---
arch/powerpc/mm/ppc_mmu_32.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
@@ -221,7 +221,7 @@ unsigned long map_mem_in_cams(unsigned long ram, int max_cam_idx, bool dryrun)#error "LOWMEM_CAM_NUM must be less than NUM_TLBCAMS"#endif-unsignedlong__initmmu_mapin_ram(unsignedlongtop)+unsignedlong__initmmu_mapin_ram(unsignedlongbase,unsignedlongtop){returntlbcam_addrs[tlbcam_index-1].limit-PAGE_OFFSET+1;}
Now that mmu_mapin_ram() is able to handle other blocks
than the one starting at 0, the WII can use it for all
its blocks.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/pgtable_32.c | 25 +++++++------------------
1 file changed, 7 insertions(+), 18 deletions(-)
@@ -254,26 +254,15 @@ static void __init __mapin_ram_chunk(unsigned long offset, unsigned long top)void__initmapin_ram(void){-unsignedlongs,top;--#ifndef CONFIG_WII-top=total_lowmem;-s=mmu_mapin_ram(0,top);-__mapin_ram_chunk(s,top);-#else-if(!wii_hole_size){-s=mmu_mapin_ram(0,total_lowmem);-__mapin_ram_chunk(s,total_lowmem);-}else{-top=wii_hole_start;-s=mmu_mapin_ram(0,top);-__mapin_ram_chunk(s,top);+structmemblock_region*reg;++for_each_memblock(memory,reg){+unsignedlongbase=reg->base;+unsignedlongtop=base+reg->size;-top=memblock_end_of_DRAM();-s=wii_mmu_mapin_mem2(top);-__mapin_ram_chunk(s,top);+base=mmu_mapin_ram(base,top);+__mapin_ram_chunk(base,top);}-#endif}/* Scan the real Linux page tables and return a PTE pointer for
Do not set IBAT when setbat() is called without _PAGE_EXEC
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/ppc_mmu_32.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
@@ -131,6 +131,7 @@ unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top)*SetuponeoftheI/DBAT(blockaddresstranslation)registerpairs.*Theparametersarenotchecked;inparticularsizemustbeapower*of2between128kand256M.+*On603+,onlysetIBATwhen_PAGE_EXECisset*/void__initsetbat(intindex,unsignedlongvirt,phys_addr_tphys,unsignedintsize,pgprot_tprot)
@@ -157,11 +158,12 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys,bat[1].batu|=1;/* Vp = 1 */if(flags&_PAGE_GUARDED){/* G bit must be zero in IBATs */-bat[0].batu=bat[0].batl=0;-}else{-/* make IBAT same as DBAT */-bat[0]=bat[1];+flags&=~_PAGE_EXEC;}+if(flags&_PAGE_EXEC)+bat[0]=bat[1];+else+bat[0].batu=bat[0].batl=0;}else{/* 601 cpu */if(bl>BL_8M)
Add a helper to know whether STRICT_KERNEL_RWX is enabled.
This is based on rodata_enabled flag which is defined only
when CONFIG_STRICT_KERNEL_RWX is selected.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/include/asm/mmu.h | 11 +++++++++++
arch/powerpc/mm/init_32.c | 4 +---
2 files changed, 12 insertions(+), 3 deletions(-)
@@ -289,6 +289,17 @@ static inline u16 get_mm_addr_key(struct mm_struct *mm, unsigned long address)}#endif /* CONFIG_PPC_MEM_KEYS */+#ifdef CONFIG_STRICT_KERNEL_RWX+staticinlineboolstrict_kernel_rwx_enabled(void)+{+returnrodata_enabled;+}+#else+staticinlineboolstrict_kernel_rwx_enabled(void)+{+returnfalse;+}+#endif#endif /* !__ASSEMBLY__ *//* The kernel use the constants below to index in the page sizes array.
CONFIG_STRICT_KERNEL_RWX requires a special alignment
for DATA for some subarches. Today it is just defined
as an #ifdef in vmlinux.lds.S
In order to get more flexibility, this patch moves the
definition of this alignment in Kconfig
On some subarches, CONFIG_STRICT_KERNEL_RWX will
require a special alignment of _etext.
This patch also adds a configuration item for it in Kconfig
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 9 +++++++++
arch/powerpc/kernel/vmlinux.lds.S | 9 +++------
2 files changed, 12 insertions(+), 6 deletions(-)
Today, STRICT_KERNEL_RWX is based on the use of regular pages
to map kernel pages.
On Book3s 32, it has three consequences:
- Using pages instead of BAT for mapping kernel linear memory severely
impacts performance.
- Exec protection is not effective because no-execute cannot be set at
page level (except on 603 which doesn't have hash tables)
- Write protection is not effective because PP bits do not provide RO
mode for kernel-only pages (except on 603 which handles it in software
via PAGE_DIRTY)
On the 603+, we have:
- Independent IBAT and DBAT allowing limitation of exec parts.
- NX bit can be set in segment registers to forbit execution on memory
mapped by pages.
- RO mode on DBATs even for kernel-only blocks.
On the 601, there is nothing much we can do other than warn the user
about it, because:
- BATs are common to instructions and data.
- BAT do not provide RO mode for kernel-only blocks.
- segment registers don't have the NX bit.
In order to use IBAT for exec protection, this patch:
- Aligns _etext to BAT block sizes (128kb)
- Set NX bit in kernel segment register (Except on vmalloc area when
CONFIG_MODULES is selected)
- Maps kernel text with IBATs.
In order to use DBAT for exec protection, this patch:
- Aligns RW DATA to BAT block sizes (4M)
- Maps kernel RO area with write prohibited DBATs
- Maps remaining memory with remaining DBATs
Here is what we get with this patch on a 832x when activating
STRICT_KERNEL_RWX:
Symbols:
c0000000 T _stext
c0680000 R __start_rodata
c0680000 R _etext
c0800000 T __init_begin
c0800000 T _sinittext
~# cat /sys/kernel/debug/block_address_translation
---[ Instruction Block Address Translation ]---
0: 0xc0000000-0xc03fffff 0x00000000 Kernel EXEC coherent
1: 0xc0400000-0xc05fffff 0x00400000 Kernel EXEC coherent
2: 0xc0600000-0xc067ffff 0x00600000 Kernel EXEC coherent
3: -
4: -
5: -
6: -
7: -
---[ Data Block Address Translation ]---
0: 0xc0000000-0xc07fffff 0x00000000 Kernel RO coherent
1: 0xc0800000-0xc0ffffff 0x00800000 Kernel RW coherent
2: 0xc1000000-0xc1ffffff 0x01000000 Kernel RW coherent
3: 0xc2000000-0xc3ffffff 0x02000000 Kernel RW coherent
4: 0xc4000000-0xc7ffffff 0x04000000 Kernel RW coherent
5: 0xc8000000-0xcfffffff 0x08000000 Kernel RW coherent
6: 0xd0000000-0xdfffffff 0x10000000 Kernel RW coherent
7: -
~# cat /sys/kernel/debug/segment_registers
---[ User Segments ]---
0x00000000-0x0fffffff Kern key 1 User key 1 VSID 0xa085d0
0x10000000-0x1fffffff Kern key 1 User key 1 VSID 0xa086e1
0x20000000-0x2fffffff Kern key 1 User key 1 VSID 0xa087f2
0x30000000-0x3fffffff Kern key 1 User key 1 VSID 0xa08903
0x40000000-0x4fffffff Kern key 1 User key 1 VSID 0xa08a14
0x50000000-0x5fffffff Kern key 1 User key 1 VSID 0xa08b25
0x60000000-0x6fffffff Kern key 1 User key 1 VSID 0xa08c36
0x70000000-0x7fffffff Kern key 1 User key 1 VSID 0xa08d47
0x80000000-0x8fffffff Kern key 1 User key 1 VSID 0xa08e58
0x90000000-0x9fffffff Kern key 1 User key 1 VSID 0xa08f69
0xa0000000-0xafffffff Kern key 1 User key 1 VSID 0xa0907a
0xb0000000-0xbfffffff Kern key 1 User key 1 VSID 0xa0918b
---[ Kernel Segments ]---
0xc0000000-0xcfffffff Kern key 0 User key 1 No Exec VSID 0x000ccc
0xd0000000-0xdfffffff Kern key 0 User key 1 No Exec VSID 0x000ddd
0xe0000000-0xefffffff Kern key 0 User key 1 No Exec VSID 0x000eee
0xf0000000-0xffffffff Kern key 0 User key 1 No Exec VSID 0x000fff
Aligning _etext to 128kb allows to map up to 32Mb text with 8 IBATs:
16Mb + 8Mb + 4Mb + 2Mb + 1Mb + 512kb + 256kb + 128kb (+ 128kb) = 32Mb
(A 9th IBAT is unneeded as 32Mb would need only a single 32Mb block)
Aligning data to 4M allows to map up to 512Mb data with 8 DBATs:
16Mb + 8Mb + 4Mb + 4Mb + 32Mb + 64Mb + 128Mb + 256Mb = 512Mb
Because some processors only have 4 BATs and because some targets need
DBATs for mapping other areas, the following patch will allow to
modify _etext and data alignment.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/asm/book3s/32/pgtable.h | 11 ++++
arch/powerpc/mm/init_32.c | 4 +-
arch/powerpc/mm/mmu_decl.h | 8 +++
arch/powerpc/mm/pgtable_32.c | 10 +++-
arch/powerpc/mm/ppc_mmu_32.c | 87 ++++++++++++++++++++++++++--
6 files changed, 112 insertions(+), 10 deletions(-)
@@ -159,6 +155,85 @@ unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top)returnbase;}+unsignedlong__initmmu_mapin_ram(unsignedlongbase,unsignedlongtop)+{+intdone;+unsignedlongborder=(unsignedlong)__init_begin-PAGE_OFFSET;++if(__map_without_bats){+pr_debug("RAM mapped without BATs\n");+return0;+}++if(!strict_kernel_rwx_enabled()||base>=border||top<=border)+return__mmu_mapin_ram(base,top);++done=__mmu_mapin_ram(base,border);+if(done!=border-base)+returndone;++returndone+__mmu_mapin_ram(border,top);+}++voidmmu_mark_initmem_nx(void)+{+intnb=mmu_has_feature(MMU_FTR_USE_HIGH_BATS)?8:4;+inti;+unsignedlongbase=(unsignedlong)_stext-PAGE_OFFSET;+unsignedlongtop=(unsignedlong)_etext-PAGE_OFFSET;+unsignedlongsize;++if(cpu_has_feature(CPU_FTR_601))+return;++for(i=0;i<nb-1&&base<top&&top-base>(128<<10);){+size=block_size(base,top);+setibat(i++,PAGE_OFFSET+base,base,size,PAGE_KERNEL_TEXT);+base+=size;+}+if(base<top){+size=block_size(base,top);+size=max(size,128UL<<10);+if((top-base)>size){+if(strict_kernel_rwx_enabled())+pr_warn("Kernel _etext not properly aligned\n");+size<<=1;+}+setibat(i++,PAGE_OFFSET+base,base,size,PAGE_KERNEL_TEXT);+base+=size;+}+for(;i<nb;i++)+clearibat(i);++update_bats();++for(i=TASK_SIZE>>28;i<16;i++){+/* Do not set NX on VM space for modules */+if(IS_ENABLED(CONFIG_MODULES)&&+(VMALLOC_START&0xf0000000)==i<<28)+break;+mtsrin(mfsrin(i<<28)|0x10000000,i<<28);+}+}++voidmmu_mark_rodata_ro(void)+{+intnb=mmu_has_feature(MMU_FTR_USE_HIGH_BATS)?8:4;+inti;++if(cpu_has_feature(CPU_FTR_601))+return;++for(i=0;i<nb;i++){+structppc_bat*bat=BATS[i];++if(bat_addrs[i].start<(unsignedlong)__init_begin)+bat[1].batl=(bat[1].batl&~BPP_RW)|BPP_RX;+}++update_bats();+}+/**SetuponeoftheI/DBAT(blockaddresstranslation)registerpairs.*Theparametersarenotchecked;inparticularsizemustbeapower
This patch implements handling of STRICT_KERNEL_RWX with
large TLBs directly in the TLB miss handlers.
To do so, etext and sinittext are aligned on 512kB boundaries
and the miss handlers use 512kB pages instead of 8Mb pages for
addresses close to the boundaries.
It sets RO PP flags for addresses under sinittext.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 2 ++
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 3 ++-
arch/powerpc/kernel/head_8xx.S | 33 ++++++++++++++++++++++++++--
arch/powerpc/mm/8xx_mmu.c | 31 +++++++++++++++++++++++++-
arch/powerpc/mm/init_32.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 2 +-
6 files changed, 67 insertions(+), 6 deletions(-)
@@ -135,6 +144,26 @@ unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top)returnmapped;}+voidmmu_mark_initmem_nx(void)+{+if(IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)&&CONFIG_ETEXT_SHIFT<23)+mmu_patch_addis(&patch__itlbmiss_linmem_top8,+-((long)_etext&~(LARGE_PAGE_SIZE_8M-1)));+if(!IS_ENABLED(CONFIG_PIN_TLB_TEXT))+mmu_patch_cmp_limit(&patch__itlbmiss_linmem_top,__pa(_etext));+}++#ifdef CONFIG_STRICT_KERNEL_RWX+voidmmu_mark_rodata_ro(void)+{+if(CONFIG_DATA_SHIFT<23)+mmu_patch_addis(&patch__dtlbmiss_romem_top8,+-__pa(((unsignedlong)_sinittext)&+~(LARGE_PAGE_SIZE_8M-1)));+mmu_patch_addis(&patch__dtlbmiss_romem_top,-__pa(_sinittext));+}+#endif+void__initsetup_initial_memory_limit(phys_addr_tfirst_memblock_base,phys_addr_tfirst_memblock_size){
On 8xx, large pages (512kb or 8M) are used to map kernel linear
memory. Aligning to 8M reduces TLB misses as only 8M pages are used
in that case.
This patchs allows the user to do it via Kconfig.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 16 ++++++++++++++--
arch/powerpc/kernel/head_8xx.S | 4 ++--
2 files changed, 16 insertions(+), 4 deletions(-)
Depending on the number of available BATs for mapping the different
kernel areas, it might be needed to increase the alignment of _etext
and/or of data areas.
This patchs allows the user to do it via Kconfig.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
This patch defined CONFIG_PPC_PAGE_SHIFT in order
to be able to use PAGE_SHIFT value inside Kconfig.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/Kconfig | 7 +++++++
arch/powerpc/include/asm/page.h | 13 ++-----------
2 files changed, 9 insertions(+), 11 deletions(-)
When CONFIG_BDI_SWITCH is set, the page tables have to be populated
allthough large TLBs are used, because the BDI switch knows nothing
about those large TLBs which are handled directly in TLB miss logic.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/pgtable_32.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
This patch reworks mmu_mapin_ram() to be more generic and map as much
blocks as possible. It now supports blocks not starting at address 0.
It scans DBATs array to find free ones instead of forcing the use of
BAT2 and BAT3.
Signed-off-by: Christophe Leroy <redacted>
---
arch/powerpc/mm/ppc_mmu_32.c | 61 +++++++++++++++++++++++++++++---------------
1 file changed, 40 insertions(+), 21 deletions(-)
@@ -73,39 +73,58 @@ unsigned long p_block_mapped(phys_addr_t pa)return0;}+staticintfind_free_bat(void)+{+intb;++if(cpu_has_feature(CPU_FTR_601)){+for(b=0;b<4;b++){+structppc_bat*bat=BATS[b];++if(!(bat[0].batl&0x40))+returnb;+}+}else{+intn=mmu_has_feature(MMU_FTR_USE_HIGH_BATS)?8:4;++for(b=0;b<n;b++){+structppc_bat*bat=BATS[b];++if(!(bat[1].batu&3))+returnb;+}+}+return-1;+}++staticunsignedintblock_size(unsignedlongbase,unsignedlongtop)+{+unsignedintmax_size=(cpu_has_feature(CPU_FTR_601)?8:256)<<20;+unsignedintbase_shift=(fls(base)-1)&31;+unsignedintblock_shift=(fls(top-base)-1)&31;++returnmin3(max_size,1U<<base_shift,1U<<block_shift);+}+unsignedlong__initmmu_mapin_ram(unsignedlongbase,unsignedlongtop){-unsignedlongtot,bl,done;-unsignedlongmax_size=(256<<20);+intidx;if(__map_without_bats){printk(KERN_DEBUG"RAM mapped without BATs\n");return0;}-/* Set up BAT2 and if necessary BAT3 to cover RAM. */+while((idx=find_free_bat())!=-1&&base!=top){+unsignedintsize=block_size(base,top);-/* Make sure we don't map a block larger than the-smallestalignmentofthephysicaladdress.*/-tot=top;-for(bl=128<<10;bl<max_size;bl<<=1){-if(bl*2>tot)+if(size<128<<10)break;+setbat(idx,PAGE_OFFSET+base,base,size,PAGE_KERNEL_X);+base+=size;}-setbat(2,PAGE_OFFSET,0,bl,PAGE_KERNEL_X);-done=(unsignedlong)bat_addrs[2].limit-PAGE_OFFSET+1;-if((done<tot)&&!bat_addrs[3].limit){-/* use BAT3 to cover a bit more */-tot-=done;-for(bl=128<<10;bl<max_size;bl<<=1)-if(bl*2>tot)-break;-setbat(3,PAGE_OFFSET+done,done,bl,PAGE_KERNEL_X);-done=(unsignedlong)bat_addrs[3].limit-PAGE_OFFSET+1;-}--returndone;+returnbase;}/*
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-13 18:16:38
On Thu, Jan 10, 2019 at 03:11:38PM +0000, Christophe Leroy wrote:
The purpose of this serie is to:
- use BATs with STRICT_KERNEL_RWX on book3s (See patch 12 for details.)
- use LTLBs with STRICT_KERNEL_RWX on 8xx (See patch 14 for a few details.)
Hi,
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
On Thu, Jan 10, 2019 at 03:11:38PM +0000, Christophe Leroy wrote:
quoted
The purpose of this serie is to:
- use BATs with STRICT_KERNEL_RWX on book3s (See patch 12 for details.)
- use LTLBs with STRICT_KERNEL_RWX on 8xx (See patch 14 for a few details.)
Hi,
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
Argh !
Can you please send the System.map file generated at compile time ?
Thanks
Christophe
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-13 21:02:38
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
quoted
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
Argh !
Can you please send the System.map file generated at compile time ?
Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
quoted
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
quoted
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
Argh !
Can you please send the System.map file generated at compile time ?
Thanks
I can't see anything special in your setup, and this failure looks rather unexpected because I can't see anything done that early when CONFIG_STRICT_KERNEL_RWX is selected.
Does CONFIG_STRICT_KERNEL_RWX works properly without my serie ?
Christophe
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-15 00:34:11
On Mon, Jan 14, 2019 at 07:23:07PM +0100, Christophe Leroy wrote:
Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
quoted
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
quoted
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
quoted
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
[...]
I can't see anything special in your setup, and this failure looks rather
unexpected because I can't see anything done that early when
CONFIG_STRICT_KERNEL_RWX is selected.
Does CONFIG_STRICT_KERNEL_RWX works properly without my serie ?
I hadn't tried this before, but yes, without this series (on v5.0-rc2),
a kernel with CONFIG_STRICT_KERNEL_RWX boots.
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 to 6 build, but fail to boot with this error:
top of MEM2 @ 13F00000
zImage starting: loaded at 0x00e00000 (sp: 0x01588fa0)
Allocating 0x14e92c8 bytes for kernel...
Decompressing (0x00000000 <- 0x00e11000:0x01586ba7)...
Done! Decompressed 0xdc01f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x15897a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval))
[ 0.000000] RAM mapped without BATs
[ 0.000000] RAM mapped without BATs
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at arch/powerpc/mm/pgtable_32.c:223!
[ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
[ 0.000000] BE PREEMPT
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00024-g596f9fe23c13 #1337
[ 0.000000] NIP: c0017c4c LR: c0a836a0 CTR: c001edc4
[ 0.000000] REGS: c0d9deb0 TRAP: 0700 Not tainted (5.0.0-rc1-wii-00024-g596f9fe23c13)
[ 0.000000] MSR: 00020030 <IR,DR> CR: 42000888 XER: 20000000
[ 0.000000]
[ 0.000000] GPR00: c0a836a0 c0d9df60 c0d2a4a0 c0d29c00 00000000 c16ff000 c0d9de28 c0dc0000
[ 0.000000] GPR08: c0d9c000 00000001 00000001 00000000 28000824 00000000 00000000 00000000
[ 0.000000] GPR16: 00000000 00000000 00000020 00000000 c0860000 c0da0000 c0000000 c0a7d000
[ 0.000000] GPR24: c0acd55c c0d487c8 13f00000 c0d29000 00000c00 00000311 c0000000 c0d487c8
[ 0.000000] NIP [c0017c4c] map_kernel_page+0x78/0xf0
[ 0.000000] LR [c0a836a0] mapin_ram+0xe0/0x14c
[ 0.000000] Call Trace:
[ 0.000000] [c0d9df60] [c0a83f54] mmu_mapin_ram+0x54/0x1a4 (unreliable)
[ 0.000000] [c0d9df90] [c0a836a0] mapin_ram+0xe0/0x14c
[ 0.000000] [c0d9dfd0] [c0a83578] MMU_init+0x158/0x1a0
[ 0.000000] [c0d9dff0] [c0003418] start_here+0x40/0x78
[ 0.000000] Instruction dump:
[ 0.000000] 55290026 57c5b53a 7ca54a14 3d204000 7f854800 3ca5c000 419e0088 81250000
[ 0.000000] 552afffe 552907fe 7d4a4b79 4082004c <0f0a0000> 54840026 7c84eb78 9081000c
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000]
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] Rebooting in 180 seconds..
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
- patches 12 to 15 build but fail to boot with this error:
top of MEM2 @ 13F00000
zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
Allocating 0x166b2c8 bytes for kernel...
Decompressing (0x00000000 <- 0x01011000:0x017880ce)...
Done! Decompressed 0xf421f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x178b7a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x00100000 bytes below 0x00000000.
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00033-gc263f8162122 #1337
[ 0.000000] Call Trace:
[ 0.000000] [c0f1ff30] [c00280f0] panic+0x144/0x324 (unreliable)
[ 0.000000] [c0f1ff90] [c0c18a34] memblock_alloc_base+0x34/0x44
[ 0.000000] [c0f1ffa0] [c0c071e0] MMU_init_hw+0xcc/0x300
[ 0.000000] [c0f1ffd0] [c0c06554] MMU_init+0x12c/0x198
[ 0.000000] [c0f1fff0] [c0003418] start_here+0x40/0x78
[ 0.000000] Rebooting in 180 seconds..
I'll investigate some more tomorrow.
Jonathan
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
On Mon, Jan 14, 2019 at 07:23:07PM +0100, Christophe Leroy wrote:
quoted
Le 13/01/2019 à 22:02, Jonathan Neuschäfer a écrit :
quoted
On Sun, Jan 13, 2019 at 08:43:07PM +0100, Christophe Leroy wrote:
quoted
Le 13/01/2019 à 19:16, Jonathan Neuschäfer a écrit :
quoted
I just tested the whole series on my Wii (I didn't test any intermediate
steps). Without CONFIG_STRICT_KERNEL_RWX, it seems to work fine, but
with it, I get the following error while booting:
[...]
quoted
I can't see anything special in your setup, and this failure looks rather
unexpected because I can't see anything done that early when
CONFIG_STRICT_KERNEL_RWX is selected.
Does CONFIG_STRICT_KERNEL_RWX works properly without my serie ?
I hadn't tried this before, but yes, without this series (on v5.0-rc2),
a kernel with CONFIG_STRICT_KERNEL_RWX boots.
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 to 6 build, but fail to boot with this error:
The bug is in patch 2, mmu_mapin_ram() should return base instead of returning 0 when __map_without_bats is set.
top of MEM2 @ 13F00000
zImage starting: loaded at 0x00e00000 (sp: 0x01588fa0)
Allocating 0x14e92c8 bytes for kernel...
Decompressing (0x00000000 <- 0x00e11000:0x01586ba7)...
Done! Decompressed 0xdc01f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x15897a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval))
[ 0.000000] RAM mapped without BATs
[ 0.000000] RAM mapped without BATs
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at arch/powerpc/mm/pgtable_32.c:223!
[ 0.000000] Oops: Exception in kernel mode, sig: 5 [#1]
[ 0.000000] BE PREEMPT
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00024-g596f9fe23c13 #1337
[ 0.000000] NIP: c0017c4c LR: c0a836a0 CTR: c001edc4
[ 0.000000] REGS: c0d9deb0 TRAP: 0700 Not tainted (5.0.0-rc1-wii-00024-g596f9fe23c13)
[ 0.000000] MSR: 00020030 <IR,DR> CR: 42000888 XER: 20000000
[ 0.000000]
[ 0.000000] GPR00: c0a836a0 c0d9df60 c0d2a4a0 c0d29c00 00000000 c16ff000 c0d9de28 c0dc0000
[ 0.000000] GPR08: c0d9c000 00000001 00000001 00000000 28000824 00000000 00000000 00000000
[ 0.000000] GPR16: 00000000 00000000 00000020 00000000 c0860000 c0da0000 c0000000 c0a7d000
[ 0.000000] GPR24: c0acd55c c0d487c8 13f00000 c0d29000 00000c00 00000311 c0000000 c0d487c8
[ 0.000000] NIP [c0017c4c] map_kernel_page+0x78/0xf0
[ 0.000000] LR [c0a836a0] mapin_ram+0xe0/0x14c
[ 0.000000] Call Trace:
[ 0.000000] [c0d9df60] [c0a83f54] mmu_mapin_ram+0x54/0x1a4 (unreliable)
[ 0.000000] [c0d9df90] [c0a836a0] mapin_ram+0xe0/0x14c
[ 0.000000] [c0d9dfd0] [c0a83578] MMU_init+0x158/0x1a0
[ 0.000000] [c0d9dff0] [c0003418] start_here+0x40/0x78
[ 0.000000] Instruction dump:
[ 0.000000] 55290026 57c5b53a 7ca54a14 3d204000 7f854800 3ca5c000 419e0088 81250000
[ 0.000000] 552afffe 552907fe 7d4a4b79 4082004c <0f0a0000> 54840026 7c84eb78 9081000c
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000]
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] Rebooting in 180 seconds..
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
Argh ! I have to squash the patch bringing the new functions with the one using them (patch 12). The result is a big messy patch which is more difficult to review but that's life.
- patches 12 to 15 build but fail to boot with this error:
Thats the one we need to really understand.
Do you have modules ? If so, can you try without ?
top of MEM2 @ 13F00000
zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
Allocating 0x166b2c8 bytes for kernel...
Decompressing (0x00000000 <- 0x01011000:0x017880ce)...
Done! Decompressed 0xf421f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x178b7a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x00100000 bytes below 0x00000000.
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00033-gc263f8162122 #1337
[ 0.000000] Call Trace:
[ 0.000000] [c0f1ff30] [c00280f0] panic+0x144/0x324 (unreliable)
[ 0.000000] [c0f1ff90] [c0c18a34] memblock_alloc_base+0x34/0x44
[ 0.000000] [c0f1ffa0] [c0c071e0] MMU_init_hw+0xcc/0x300
[ 0.000000] [c0f1ffd0] [c0c06554] MMU_init+0x12c/0x198
[ 0.000000] [c0f1fff0] [c0003418] start_here+0x40/0x78
[ 0.000000] Rebooting in 180 seconds..
I'll investigate some more tomorrow.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-01-15 10:22:40
Christophe Leroy [off-list ref] writes:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
quoted
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
Argh ! I have to squash the patch bringing the new functions with the
one using them (patch 12). The result is a big messy patch which is more
difficult to review but that's life.
You don't *have* to squash them.
We like to preserve bisectability, but it's not a 100% hard requirement.
Someone trying to bisect through those patches can always turn off
-Werror with PPC_DISABLE_WERROR. But they probably can just skip them
because they just add new code that's not called yet.
So I won't object if you send them as-is.
cheers
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
quoted
quoted
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
Argh ! I have to squash the patch bringing the new functions with the
one using them (patch 12). The result is a big messy patch which is more
difficult to review but that's life.
You don't *have* to squash them.
We like to preserve bisectability, but it's not a 100% hard requirement.
Someone trying to bisect through those patches can always turn off
-Werror with PPC_DISABLE_WERROR. But they probably can just skip them
because they just add new code that's not called yet.
Ok thanks for the note.
So I won't object if you send them as-is.
Good to know. Anyway I think I will at least re-order so that the patch using the new functions immediatly follows the one adding the functions.
Christophe
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-16 00:36:27
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
quoted
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 to 6 build, but fail to boot with this error:
The bug is in patch 2, mmu_mapin_ram() should return base instead of
returning 0 when __map_without_bats is set.
Indeed, with this change, I can boot up to patch 11.
quoted
- patches 12 to 15 build but fail to boot with this error:
Thats the one we need to really understand.
Do you have modules ? If so, can you try without ?
I don't use any modules in my test setup, but I have module support
enabled. Disabling CONFIG_MODULES makes no difference, as far as I can
see (I get the same backtrace with memblock_alloc_base+0x34/0x44).
With a few printks[1], I traced this error, and got the following
result:
[ 0.000000] __memblock_find_range_top_down(1000:1800000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] __memblock_find_range_top_down: in loop, 179962d:1800000
[ 0.000000] __memblock_find_range_top_down: in loop, 1676000:17987a0
[ 0.000000] __memblock_find_range_top_down: nothing found :(
The limit of 0x1800000 comes from setup_initial_memory_limit, which only
considers the first memblock, but the second memblock starts at 256MiB,
so it wouldn't be usable anyway, according to the comment in
setup_initial_memory_limit.
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Jonathan
[1]:
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
On Tue, Jan 15, 2019 at 07:51:01AM +0100, Christophe Leroy wrote:
quoted
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
[...]
quoted
quoted
I've checked it patch-by-patch now (with STRICT_KERNEL_RWX):
- patches 1 and 2 build and boot fine
- patches 3 to 6 build, but fail to boot with this error:
The bug is in patch 2, mmu_mapin_ram() should return base instead of
returning 0 when __map_without_bats is set.
Indeed, with this change, I can boot up to patch 11.
quoted
quoted
- patches 12 to 15 build but fail to boot with this error:
Thats the one we need to really understand.
Do you have modules ? If so, can you try without ?
I don't use any modules in my test setup, but I have module support
enabled. Disabling CONFIG_MODULES makes no difference, as far as I can
see (I get the same backtrace with memblock_alloc_base+0x34/0x44).
With a few printks[1], I traced this error, and got the following
result:
[ 0.000000] __memblock_find_range_top_down(1000:1800000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] __memblock_find_range_top_down: in loop, 179962d:1800000
[ 0.000000] __memblock_find_range_top_down: in loop, 1676000:17987a0
[ 0.000000] __memblock_find_range_top_down: nothing found :(
The limit of 0x1800000 comes from setup_initial_memory_limit, which only
considers the first memblock, but the second memblock starts at 256MiB,
so it wouldn't be usable anyway, according to the comment in
setup_initial_memory_limit.
Yes, initial_bats() in head_32.S sets one 256Mb BAT for initial booting:
/*
* On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET
* (we keep one for debugging) and on others, we use one 256M BAT.
*/
initial_bats:
lis r11,PAGE_OFFSET@h
mfspr r9,SPRN_PVR
rlwinm r9,r9,16,16,31 /* r9 = 1 for 601, 4 for 604 */
cmpwi 0,r9,1
bne 4f
...
4: tophys(r8,r11)
#ifdef CONFIG_SMP
ori r8,r8,0x12 /* R/W access, M=1 */
#else
ori r8,r8,2 /* R/W access */
#endif /* CONFIG_SMP */
ori r11,r11,BL_256M<<2|0x2 /* set up BAT registers for 604 */
mtspr SPRN_DBAT0L,r8 /* N.B. 6xx (not 601) have valid */
mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */
mtspr SPRN_IBAT0L,r8
mtspr SPRN_IBAT0U,r11
isync
blr
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT, does it helps ?
@@ -259,6 +259,8 @@ void setup_initial_memory_limit(phys_addr_t first_memblock_base,/* 601 can only access 16MB at the moment */if(PVR_VER(mfspr(SPRN_PVR))==1)memblock_set_current_limit(min_t(u64,first_memblock_size,0x01000000));+elseif(IS_ENABLED(CONFIG_WII))+memblock_set_current_limit(min_t(u64,first_memblock_size,0x20000000));else/* Anything else has 256M mapped */memblock_set_current_limit(min_t(u64,first_memblock_size,0x10000000));}
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-16 13:16:50
On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
quoted hunk
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
quoted
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT, does it
helps ?
first_memblock_base,
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
+ else if (IS_ENABLED(CONFIG_WII))
+ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
else /* Anything else has 256M mapped */
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
}
I haven't tested it, but this patch won't be enough, because we're only
looking at the first memblock, and the additional memory in the Wii
(MEM2) is the second memblock.
Jonathan
Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit :
On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
quoted
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
quoted
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT, does it
helps ?
first_memblock_base,
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
+ else if (IS_ENABLED(CONFIG_WII))
+ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
else /* Anything else has 256M mapped */
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
}
I haven't tested it, but this patch won't be enough, because we're only
looking at the first memblock, and the additional memory in the Wii
(MEM2) is the second memblock.
Yes right.
Would the following work instead ?
memblock_set_current_limit(0x20000000);
Christophe
From: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Date: 2019-01-16 23:48:33
On Wed, Jan 16, 2019 at 02:34:53PM +0100, Christophe Leroy wrote:
Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit :
quoted
On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
quoted
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
quoted
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT, does it
helps ?
first_memblock_base,
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
+ else if (IS_ENABLED(CONFIG_WII))
+ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
else /* Anything else has 256M mapped */
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
}
I haven't tested it, but this patch won't be enough, because we're only
looking at the first memblock, and the additional memory in the Wii
(MEM2) is the second memblock.
Yes right.
Would the following work instead ?
memblock_set_current_limit(0x20000000);
With the config at https://gist.githubusercontent.com/neuschaefer/12ccc87ff8aeff543fad558e8742cd2b/raw/d49d321709cac364779e6893bbd91ff5a80bcb03/config
it still doesn't boot, but with a different error:
top of MEM2 @ 13F00000
zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
Allocating 0x166b2c8 bytes for kernel...
Decompressing (0x00000000 <- 0x01011000:0x01788799)...
Done! Decompressed 0xf421f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x178b7a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] Total memory = 319MB; using 1024kB for hash table (at d3e00000)
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13e00000
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13dff000
[ 0.000000] BUG: Unable to handle kernel data access at 0xc106a434
[ 0.000000] Faulting instruction address: 0xc0071bf4
[ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.000000] BE PREEMPT
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00038-gc34b70d591b6-dirty #1337
[ 0.000000] NIP: c0071bf4 LR: c00727d8 CTR: 00000000
[ 0.000000] REGS: c0f1fd30 TRAP: 0300 Not tainted (5.0.0-rc1-wii-00038-gc34b70d591b6-dirty)
[ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 44002842 XER: 00000000
[ 0.000000] DAR: c106a434 DSISR: 40000000
[ 0.000000] GPR00: c0074a98 c0f1fde0 c0ead4a0 c0ead4a0 c0ead9c8 00000008 00000000 00000000
[ 0.000000] GPR08: 00000003 c106a418 00000258 00000001 24000444 fb43ef5b c0f30000 7561f327
[ 0.000000] GPR16: c0f40000 691cfd11 38afe359 f161e513 00000000 c0ead9c8 00000001 00000000
[ 0.000000] GPR24: 00000000 c0f46288 00000000 c0ead4a0 c0ead9c8 00000008 c0ead4a0 00000100
[ 0.000000] NIP [c0071bf4] mark_lock+0x64/0x858
[ 0.000000] LR [c00727d8] __lock_acquire+0x334/0x1a40
[ 0.000000] Call Trace:
[ 0.000000] [c0f1fe20] [00000006] 0x6
[ 0.000000] [c0f1fed0] [c0074a98] lock_acquire+0x110/0x20c
[ 0.000000] [c0f1ff10] [c085e8cc] _raw_spin_lock+0x44/0x60
[ 0.000000] [c0f1ff30] [c007f220] vprintk_emit+0xa0/0x328
[ 0.000000] [c0f1ff70] [c007fc48] printk+0x5c/0x84
[ 0.000000] [c0f1ffb0] [c0c00854] start_kernel+0x64/0x460
[ 0.000000] [c0f1fff0] [00003438] 0x3438
[ 0.000000] Instruction dump:
[ 0.000000] 41820170 55086cfe 550a083c 7d4a4214 554a1838 3d20c0f4 7d4a4214 39296288
[ 0.000000] 554a1838 3d290012 7d295214 39293f38 <8129001c> 7fe94839 41820028 3bc00001
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000]
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
Not sure what's wrong. It does work with wii_defconfig, though.
I think for now I'm happy without this patch, as it doesn't seem to be
really necessary.
Jonathan
Le 17/01/2019 à 00:48, Jonathan Neuschäfer a écrit :
On Wed, Jan 16, 2019 at 02:34:53PM +0100, Christophe Leroy wrote:
quoted
Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit :
quoted
On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
quoted
Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
quoted
Thinning the kernel down a bit actually makes it boot again. Ooops...!
Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
fail the hash table allocation, but there may have been other factors
involved (I'm not sure exactly). Sorry for the confusion!
Ok, that must be the reason. Thanks for testing.
What about the following modification which maps a second 256Mb BAT, does it
helps ?
first_memblock_base,
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
+ else if (IS_ENABLED(CONFIG_WII))
+ memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
else /* Anything else has 256M mapped */
memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
}
I haven't tested it, but this patch won't be enough, because we're only
looking at the first memblock, and the additional memory in the Wii
(MEM2) is the second memblock.
Yes right.
Would the following work instead ?
memblock_set_current_limit(0x20000000);
With the config at https://gist.githubusercontent.com/neuschaefer/12ccc87ff8aeff543fad558e8742cd2b/raw/d49d321709cac364779e6893bbd91ff5a80bcb03/config
it still doesn't boot, but with a different error:
top of MEM2 @ 13F00000
zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
Allocating 0x166b2c8 bytes for kernel...
Decompressing (0x00000000 <- 0x01011000:0x01788799)...
Done! Decompressed 0xf421f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x178b7a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] Total memory = 319MB; using 1024kB for hash table (at d3e00000)
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13e00000
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13dff000
[ 0.000000] BUG: Unable to handle kernel data access at 0xc106a434
[ 0.000000] Faulting instruction address: 0xc0071bf4
[ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.000000] BE PREEMPT
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00038-gc34b70d591b6-dirty #1337
[ 0.000000] NIP: c0071bf4 LR: c00727d8 CTR: 00000000
[ 0.000000] REGS: c0f1fd30 TRAP: 0300 Not tainted (5.0.0-rc1-wii-00038-gc34b70d591b6-dirty)
[ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 44002842 XER: 00000000
[ 0.000000] DAR: c106a434 DSISR: 40000000
[ 0.000000] GPR00: c0074a98 c0f1fde0 c0ead4a0 c0ead4a0 c0ead9c8 00000008 00000000 00000000
[ 0.000000] GPR08: 00000003 c106a418 00000258 00000001 24000444 fb43ef5b c0f30000 7561f327
[ 0.000000] GPR16: c0f40000 691cfd11 38afe359 f161e513 00000000 c0ead9c8 00000001 00000000
[ 0.000000] GPR24: 00000000 c0f46288 00000000 c0ead4a0 c0ead9c8 00000008 c0ead4a0 00000100
[ 0.000000] NIP [c0071bf4] mark_lock+0x64/0x858
[ 0.000000] LR [c00727d8] __lock_acquire+0x334/0x1a40
[ 0.000000] Call Trace:
[ 0.000000] [c0f1fe20] [00000006] 0x6
[ 0.000000] [c0f1fed0] [c0074a98] lock_acquire+0x110/0x20c
[ 0.000000] [c0f1ff10] [c085e8cc] _raw_spin_lock+0x44/0x60
[ 0.000000] [c0f1ff30] [c007f220] vprintk_emit+0xa0/0x328
[ 0.000000] [c0f1ff70] [c007fc48] printk+0x5c/0x84
[ 0.000000] [c0f1ffb0] [c0c00854] start_kernel+0x64/0x460
[ 0.000000] [c0f1fff0] [00003438] 0x3438
[ 0.000000] Instruction dump:
[ 0.000000] 41820170 55086cfe 550a083c 7d4a4214 554a1838 3d20c0f4 7d4a4214 39296288
[ 0.000000] 554a1838 3d290012 7d295214 39293f38 <8129001c> 7fe94839 41820028 3bc00001
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000]
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
Not sure what's wrong. It does work with wii_defconfig, though.
I think for now I'm happy without this patch, as it doesn't seem to be
really necessary.
That's strange, 0xc106a434 is within the first block, should not be a problem, should it ?
According to DSISR, the fault is due to: Set if the translation of an attempted access is not found in the primary or secondary hash table entry
group (HTEG), or in the range of a DBAT register (page fault condition)
Ok, won't spend more time on that for now, 24Mbytes should be OK for early init in most cases.
Christophe
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-02-20 13:23:17
Christophe Leroy [off-list ref] writes:
Le 15/01/2019 à 11:22, Michael Ellerman a écrit :
quoted
Christophe Leroy [off-list ref] writes:
quoted
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
quoted
quoted
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
Argh ! I have to squash the patch bringing the new functions with the
one using them (patch 12). The result is a big messy patch which is more
difficult to review but that's life.
You don't *have* to squash them.
We like to preserve bisectability, but it's not a 100% hard requirement.
Someone trying to bisect through those patches can always turn off
-Werror with PPC_DISABLE_WERROR. But they probably can just skip them
because they just add new code that's not called yet.
Ok thanks for the note.
quoted
So I won't object if you send them as-is.
Good to know. Anyway I think I will at least re-order so that the patch
using the new functions immediatly follows the one adding the functions.
Based on that I'm expecting a v3 of this series, right?
cheers
Le 15/01/2019 à 01:33, Jonathan Neuschäfer a écrit :
...
quoted
quoted
- patches 7 to 11 fail to build with this error (really a warning, but
arch/powerpc doesn't allow warnings by default):
CC arch/powerpc/mm/ppc_mmu_32.o
../arch/powerpc/mm/ppc_mmu_32.c:133:13: error: ‘clearibat’ defined but not used [-Werror=unused-function]
static void clearibat(int index)
^~~~~~~~~
../arch/powerpc/mm/ppc_mmu_32.c:115:13: error: ‘setibat’ defined but not used [-Werror=unused-function]
static void setibat(int index, unsigned long virt, phys_addr_t phys,
^~~~~~~
cc1: all warnings being treated as errors
Argh ! I have to squash the patch bringing the new functions with the
one using them (patch 12). The result is a big messy patch which is more
difficult to review but that's life.
You don't *have* to squash them.
We like to preserve bisectability, but it's not a 100% hard requirement.
Someone trying to bisect through those patches can always turn off
-Werror with PPC_DISABLE_WERROR. But they probably can just skip them
because they just add new code that's not called yet.
Ok thanks for the note.
quoted
So I won't object if you send them as-is.
Good to know. Anyway I think I will at least re-order so that the patch
using the new functions immediatly follows the one adding the functions.
Based on that I'm expecting a v3 of this series, right?