* [BISECTED] kexec regression on PowerBook G4
@ 2019-05-21 22:18 Aaro Koskinen
2019-05-22 6:14 ` Christophe Leroy
0 siblings, 1 reply; 20+ messages in thread
From: Aaro Koskinen @ 2019-05-21 22:18 UTC (permalink / raw)
To: Michael Ellerman, Christophe Leroy, linuxppc-dev
Hi,
I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when trying
to kexec a kernel the system gets stuck (no errors seen on the console).
Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address
in a SPRG"). This commit doesn't revert cleanly anymore but I tested
that the one before works OK.
With current Linus HEAD (9c7db5004280), it gets a bit further but still
doesn't work: now I get an error on the console after kexec "Starting
new kernel! ... Bye!":
kernel tried to execute exec-protected page (...) - exploit attempt?
A.
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-21 22:18 [BISECTED] kexec regression on PowerBook G4 Aaro Koskinen @ 2019-05-22 6:14 ` Christophe Leroy 2019-05-22 7:44 ` Christophe Leroy 2019-05-22 20:07 ` [BISECTED] kexec regression on PowerBook G4 Aaro Koskinen 0 siblings, 2 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-22 6:14 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Hi Aero, Le 22/05/2019 à 00:18, Aaro Koskinen a écrit : > Hi, > > I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when trying > to kexec a kernel the system gets stuck (no errors seen on the console). Do you mean you are trying to kexec a v5.1 kernel from a v5.0 kernel, or do you have a working v5.1 kernel, but kexec doesn't work with it ? > > Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address > in a SPRG"). This commit doesn't revert cleanly anymore but I tested > that the one before works OK. Not sure that's the problem. There was a problem with that commit, but it was fixed by 4622a2d43101 ("powerpc/6xx: fix setup and use of SPRN_SPRG_PGDIR for hash32"). You probably hit some commit between those two during bisect, that's likely the reason why you ended here. Can you restart your bisect from 4622a2d43101 ? If you have CONFIG_SMP, maybe you should also consider taking 397d2300b08c ("powerpc/32s: fix flush_hash_pages() on SMP"). Stable 5.1.4 includes it. > > With current Linus HEAD (9c7db5004280), it gets a bit further but still > doesn't work: now I get an error on the console after kexec "Starting > new kernel! ... Bye!": > > kernel tried to execute exec-protected page (...) - exploit attempt? Interesting. Do you have CONFIG_STRICT_KERNEL_RWX=y in your .config ? If so, can you retry without it ? Thanks Christophe > > A. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-22 6:14 ` Christophe Leroy @ 2019-05-22 7:44 ` Christophe Leroy 2019-05-22 20:13 ` Aaro Koskinen 2019-05-22 20:07 ` [BISECTED] kexec regression on PowerBook G4 Aaro Koskinen 1 sibling, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-22 7:44 UTC (permalink / raw) To: Aaro Koskinen, Michael Ellerman; +Cc: linuxppc-dev Hi Again, On 05/22/2019 06:14 AM, Christophe Leroy wrote: > Hi Aero, > > Le 22/05/2019 à 00:18, Aaro Koskinen a écrit : >> Hi, >> >> I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when >> trying >> to kexec a kernel the system gets stuck (no errors seen on the console). > > Do you mean you are trying to kexec a v5.1 kernel from a v5.0 kernel, or > do you have a working v5.1 kernel, but kexec doesn't work with it ? > >> >> Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address >> in a SPRG"). This commit doesn't revert cleanly anymore but I tested >> that the one before works OK. > > Not sure that's the problem. There was a problem with that commit, but > it was fixed by 4622a2d43101 ("powerpc/6xx: fix setup and use of > SPRN_SPRG_PGDIR for hash32"). > You probably hit some commit between those two during bisect, that's > likely the reason why you ended here. > > Can you restart your bisect from 4622a2d43101 ? > > If you have CONFIG_SMP, maybe you should also consider taking > 397d2300b08c ("powerpc/32s: fix flush_hash_pages() on SMP"). Stable > 5.1.4 includes it. > >> >> With current Linus HEAD (9c7db5004280), it gets a bit further but still >> doesn't work: now I get an error on the console after kexec "Starting >> new kernel! ... Bye!": >> >> kernel tried to execute exec-protected page (...) - exploit attempt? > > Interesting. > > Do you have CONFIG_STRICT_KERNEL_RWX=y in your .config ? If so, can you > retry without it ? After looking at the code, I don't thing CONFIG_STRICT_KERNEL_RWX will make any difference. Can you try the patch below ? From 8c1039da0d0f26cdf995156a905fc97fe7bda36c Mon Sep 17 00:00:00 2001 From: Christophe Leroy <christophe.leroy@c-s.fr> Date: Wed, 22 May 2019 07:28:42 +0000 Subject: [PATCH] Fix Kexec --- arch/powerpc/include/asm/pgtable.h | 2 ++ arch/powerpc/kernel/machine_kexec_32.c | 4 ++++ arch/powerpc/mm/pgtable_32.c | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h index 3f53be60fb01..642eea937229 100644 --- a/arch/powerpc/include/asm/pgtable.h +++ b/arch/powerpc/include/asm/pgtable.h @@ -140,6 +140,8 @@ static inline void pte_frag_set(mm_context_t *ctx, void *p) } #endif +int change_page_attr(struct page *page, int numpages, pgprot_t prot); + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_PGTABLE_H */ diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c index affe5dcce7f4..4f719501e6ae 100644 --- a/arch/powerpc/kernel/machine_kexec_32.c +++ b/arch/powerpc/kernel/machine_kexec_32.c @@ -54,6 +54,10 @@ void default_machine_kexec(struct kimage *image) memcpy((void *)reboot_code_buffer, relocate_new_kernel, relocate_new_kernel_size); + change_page_attr(image->control_code_page, + ALIGN(KEXEC_CONTROL_PAGE_SIZE, PAGE_SIZE) >> PAGE_SHIFT, + PAGE_KERNEL_TEXT); + flush_icache_range(reboot_code_buffer, reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); printk(KERN_INFO "Bye!\n"); diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c index 16ada373b32b..0e4651d803fc 100644 --- a/arch/powerpc/mm/pgtable_32.c +++ b/arch/powerpc/mm/pgtable_32.c @@ -340,7 +340,7 @@ static int __change_page_attr_noflush(struct page *page, pgprot_t prot) * * THIS DOES NOTHING WITH BAT MAPPINGS, DEBUG USE ONLY */ -static int change_page_attr(struct page *page, int numpages, pgprot_t prot) +int change_page_attr(struct page *page, int numpages, pgprot_t prot) { int i, err = 0; unsigned long flags; -- 2.13.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-22 7:44 ` Christophe Leroy @ 2019-05-22 20:13 ` Aaro Koskinen 2019-05-22 20:33 ` LEROY Christophe 0 siblings, 1 reply; 20+ messages in thread From: Aaro Koskinen @ 2019-05-22 20:13 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Wed, May 22, 2019 at 07:44:56AM +0000, Christophe Leroy wrote: > On 05/22/2019 06:14 AM, Christophe Leroy wrote: > >Le 22/05/2019 à 00:18, Aaro Koskinen a écrit : > >>I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when > >>trying > >>to kexec a kernel the system gets stuck (no errors seen on the console). > > > >Do you mean you are trying to kexec a v5.1 kernel from a v5.0 kernel, or > >do you have a working v5.1 kernel, but kexec doesn't work with it ? > > > >> > >>Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address > >>in a SPRG"). This commit doesn't revert cleanly anymore but I tested > >>that the one before works OK. > > > >Not sure that's the problem. There was a problem with that commit, but it > >was fixed by 4622a2d43101 ("powerpc/6xx: fix setup and use of > >SPRN_SPRG_PGDIR for hash32"). > >You probably hit some commit between those two during bisect, that's > >likely the reason why you ended here. > > > >Can you restart your bisect from 4622a2d43101 ? > > > >If you have CONFIG_SMP, maybe you should also consider taking 397d2300b08c > >("powerpc/32s: fix flush_hash_pages() on SMP"). Stable 5.1.4 includes it. > > > >> > >>With current Linus HEAD (9c7db5004280), it gets a bit further but still > >>doesn't work: now I get an error on the console after kexec "Starting > >>new kernel! ... Bye!": > >> > >> kernel tried to execute exec-protected page (...) - exploit attempt? > > > >Interesting. > > > >Do you have CONFIG_STRICT_KERNEL_RWX=y in your .config ? If so, can you > >retry without it ? > > After looking at the code, I don't thing CONFIG_STRICT_KERNEL_RWX will make > any difference. Can you try the patch below ? Doesn't help (git refuses the patch as corrupted, so I had to do those changes manually, but I'm pretty sure I got it right). I still get the "kernel tried to execute exec-protected page...". What should I try next? A. > From 8c1039da0d0f26cdf995156a905fc97fe7bda36c Mon Sep 17 00:00:00 2001 > From: Christophe Leroy <christophe.leroy@c-s.fr> > Date: Wed, 22 May 2019 07:28:42 +0000 > Subject: [PATCH] Fix Kexec > > --- > arch/powerpc/include/asm/pgtable.h | 2 ++ > arch/powerpc/kernel/machine_kexec_32.c | 4 ++++ > arch/powerpc/mm/pgtable_32.c | 2 +- > 3 files changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/pgtable.h > b/arch/powerpc/include/asm/pgtable.h > index 3f53be60fb01..642eea937229 100644 > --- a/arch/powerpc/include/asm/pgtable.h > +++ b/arch/powerpc/include/asm/pgtable.h > @@ -140,6 +140,8 @@ static inline void pte_frag_set(mm_context_t *ctx, void > *p) > } > #endif > > +int change_page_attr(struct page *page, int numpages, pgprot_t prot); > + > #endif /* __ASSEMBLY__ */ > > #endif /* _ASM_POWERPC_PGTABLE_H */ > diff --git a/arch/powerpc/kernel/machine_kexec_32.c > b/arch/powerpc/kernel/machine_kexec_32.c > index affe5dcce7f4..4f719501e6ae 100644 > --- a/arch/powerpc/kernel/machine_kexec_32.c > +++ b/arch/powerpc/kernel/machine_kexec_32.c > @@ -54,6 +54,10 @@ void default_machine_kexec(struct kimage *image) > memcpy((void *)reboot_code_buffer, relocate_new_kernel, > relocate_new_kernel_size); > > + change_page_attr(image->control_code_page, > + ALIGN(KEXEC_CONTROL_PAGE_SIZE, PAGE_SIZE) >> PAGE_SHIFT, > + PAGE_KERNEL_TEXT); > + > flush_icache_range(reboot_code_buffer, > reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); > printk(KERN_INFO "Bye!\n"); > diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c > index 16ada373b32b..0e4651d803fc 100644 > --- a/arch/powerpc/mm/pgtable_32.c > +++ b/arch/powerpc/mm/pgtable_32.c > @@ -340,7 +340,7 @@ static int __change_page_attr_noflush(struct page *page, > pgprot_t prot) > * > * THIS DOES NOTHING WITH BAT MAPPINGS, DEBUG USE ONLY > */ > -static int change_page_attr(struct page *page, int numpages, pgprot_t prot) > +int change_page_attr(struct page *page, int numpages, pgprot_t prot) > { > int i, err = 0; > unsigned long flags; > -- > 2.13.3 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-22 20:13 ` Aaro Koskinen @ 2019-05-22 20:33 ` LEROY Christophe [not found] ` <20190522211724.GC456@darkstar.musicnaut.iki.fi> 0 siblings, 1 reply; 20+ messages in thread From: LEROY Christophe @ 2019-05-22 20:33 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Aaro Koskinen <aaro.koskinen@iki.fi> a écrit : > Hi, > > On Wed, May 22, 2019 at 07:44:56AM +0000, Christophe Leroy wrote: >> On 05/22/2019 06:14 AM, Christophe Leroy wrote: >> >Le 22/05/2019 à 00:18, Aaro Koskinen a écrit : >> >>I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when >> >>trying >> >>to kexec a kernel the system gets stuck (no errors seen on the console). >> > >> >Do you mean you are trying to kexec a v5.1 kernel from a v5.0 kernel, or >> >do you have a working v5.1 kernel, but kexec doesn't work with it ? >> > >> >> >> >>Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address >> >>in a SPRG"). This commit doesn't revert cleanly anymore but I tested >> >>that the one before works OK. >> > >> >Not sure that's the problem. There was a problem with that commit, but it >> >was fixed by 4622a2d43101 ("powerpc/6xx: fix setup and use of >> >SPRN_SPRG_PGDIR for hash32"). >> >You probably hit some commit between those two during bisect, that's >> >likely the reason why you ended here. >> > >> >Can you restart your bisect from 4622a2d43101 ? >> > >> >If you have CONFIG_SMP, maybe you should also consider taking 397d2300b08c >> >("powerpc/32s: fix flush_hash_pages() on SMP"). Stable 5.1.4 includes it. >> > >> >> >> >>With current Linus HEAD (9c7db5004280), it gets a bit further but still >> >>doesn't work: now I get an error on the console after kexec "Starting >> >>new kernel! ... Bye!": >> >> >> >> kernel tried to execute exec-protected page (...) - exploit attempt? >> > >> >Interesting. >> > >> >Do you have CONFIG_STRICT_KERNEL_RWX=y in your .config ? If so, can you >> >retry without it ? >> >> After looking at the code, I don't thing CONFIG_STRICT_KERNEL_RWX will make >> any difference. Can you try the patch below ? > > Doesn't help (git refuses the patch as corrupted, so I had to do those > changes manually, but I'm pretty sure I got it right). > > I still get the "kernel tried to execute exec-protected page...". What > should I try next? Can you provide full details of the Oops you get ? And also your System.map ? K Also build with CONFIG_PPC_PTDUMP and mount /sys/kernel/debug and give content of /sys/kernel/debug/powerpc/block_address_translation and .../segment_registers before the failing kexec, and also /sys/kernel/debug/kernel_page_tables Thx Christophe > > A. > >> From 8c1039da0d0f26cdf995156a905fc97fe7bda36c Mon Sep 17 00:00:00 2001 >> From: Christophe Leroy <christophe.leroy@c-s.fr> >> Date: Wed, 22 May 2019 07:28:42 +0000 >> Subject: [PATCH] Fix Kexec >> >> --- >> arch/powerpc/include/asm/pgtable.h | 2 ++ >> arch/powerpc/kernel/machine_kexec_32.c | 4 ++++ >> arch/powerpc/mm/pgtable_32.c | 2 +- >> 3 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/include/asm/pgtable.h >> b/arch/powerpc/include/asm/pgtable.h >> index 3f53be60fb01..642eea937229 100644 >> --- a/arch/powerpc/include/asm/pgtable.h >> +++ b/arch/powerpc/include/asm/pgtable.h >> @@ -140,6 +140,8 @@ static inline void pte_frag_set(mm_context_t *ctx, void >> *p) >> } >> #endif >> >> +int change_page_attr(struct page *page, int numpages, pgprot_t prot); >> + >> #endif /* __ASSEMBLY__ */ >> >> #endif /* _ASM_POWERPC_PGTABLE_H */ >> diff --git a/arch/powerpc/kernel/machine_kexec_32.c >> b/arch/powerpc/kernel/machine_kexec_32.c >> index affe5dcce7f4..4f719501e6ae 100644 >> --- a/arch/powerpc/kernel/machine_kexec_32.c >> +++ b/arch/powerpc/kernel/machine_kexec_32.c >> @@ -54,6 +54,10 @@ void default_machine_kexec(struct kimage *image) >> memcpy((void *)reboot_code_buffer, relocate_new_kernel, >> relocate_new_kernel_size); >> >> + change_page_attr(image->control_code_page, >> + ALIGN(KEXEC_CONTROL_PAGE_SIZE, PAGE_SIZE) >> PAGE_SHIFT, >> + PAGE_KERNEL_TEXT); >> + >> flush_icache_range(reboot_code_buffer, >> reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); >> printk(KERN_INFO "Bye!\n"); >> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c >> index 16ada373b32b..0e4651d803fc 100644 >> --- a/arch/powerpc/mm/pgtable_32.c >> +++ b/arch/powerpc/mm/pgtable_32.c >> @@ -340,7 +340,7 @@ static int __change_page_attr_noflush(struct page *page, >> pgprot_t prot) >> * >> * THIS DOES NOTHING WITH BAT MAPPINGS, DEBUG USE ONLY >> */ >> -static int change_page_attr(struct page *page, int numpages, pgprot_t prot) >> +int change_page_attr(struct page *page, int numpages, pgprot_t prot) >> { >> int i, err = 0; >> unsigned long flags; >> -- >> 2.13.3 ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <20190522211724.GC456@darkstar.musicnaut.iki.fi>]
* [RFC PATCH] powerpc: fix kexec failure on book3s/32 [not found] ` <20190522211724.GC456@darkstar.musicnaut.iki.fi> @ 2019-05-23 5:24 ` Christophe Leroy 2019-05-23 5:33 ` [BISECTED] kexec regression on PowerBook G4 Christophe Leroy 2019-05-24 6:05 ` Christophe Leroy 2 siblings, 0 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-23 5:24 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- arch/powerpc/kernel/machine_kexec_32.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c index affe5dcce7f4..b6a4250b9ee0 100644 --- a/arch/powerpc/kernel/machine_kexec_32.c +++ b/arch/powerpc/kernel/machine_kexec_32.c @@ -54,6 +54,8 @@ void default_machine_kexec(struct kimage *image) memcpy((void *)reboot_code_buffer, relocate_new_kernel, relocate_new_kernel_size); + mtsrin(mfsrin(reboot_code_buffer) & ~SR_NX, reboot_code_buffer); + flush_icache_range(reboot_code_buffer, reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); printk(KERN_INFO "Bye!\n"); -- 2.13.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 [not found] ` <20190522211724.GC456@darkstar.musicnaut.iki.fi> 2019-05-23 5:24 ` [RFC PATCH] powerpc: fix kexec failure on book3s/32 Christophe Leroy @ 2019-05-23 5:33 ` Christophe Leroy 2019-05-23 17:27 ` Aaro Koskinen 2019-05-24 6:05 ` Christophe Leroy 2 siblings, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-23 5:33 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Hi, Le 22/05/2019 à 23:17, Aaro Koskinen a écrit : > Hi, > > On Wed, May 22, 2019 at 10:33:35PM +0200, LEROY Christophe wrote: >> Can you provide full details of the Oops you get ? And also your System.map ? > > System.map is below. The oops log is attached as jpeg (crappy camera > shoot, apologies, I hope it gets through) as the only way I can see it > is the frame buffer display. > >> Also build with CONFIG_PPC_PTDUMP and mount /sys/kernel/debug and give >> content of /sys/kernel/debug/powerpc/block_address_translation and >> .../segment_registers before the failing kexec, and also >> /sys/kernel/debug/kernel_page_tables > > The kernel that fails is essentially headless without any input access. I > could probably do this if needed, but it's going to take a while... > Ok, the Oops confirms that the error is due to executing the kexec control code which is located outside the kernel text area. My yesterday's proposed change doesn't work because on book3S/32, NX protection is based on setting segments to NX, and using IBATs for kernel text. Can you try the patch I sent out a few minutes ago ? (https://patchwork.ozlabs.org/patch/1103827/) Thanks Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-23 5:33 ` [BISECTED] kexec regression on PowerBook G4 Christophe Leroy @ 2019-05-23 17:27 ` Aaro Koskinen 2019-05-23 18:58 ` Christophe Leroy 0 siblings, 1 reply; 20+ messages in thread From: Aaro Koskinen @ 2019-05-23 17:27 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote: > Ok, the Oops confirms that the error is due to executing the kexec control > code which is located outside the kernel text area. > > My yesterday's proposed change doesn't work because on book3S/32, NX > protection is based on setting segments to NX, and using IBATs for kernel > text. > > Can you try the patch I sent out a few minutes ago ? > (https://patchwork.ozlabs.org/patch/1103827/) It now crashes with "BUG: Unable to handle kernel instruction fetch" and the faulting address is 0xef13a000. A. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-23 17:27 ` Aaro Koskinen @ 2019-05-23 18:58 ` Christophe Leroy 2019-05-23 22:23 ` Aaro Koskinen 0 siblings, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-23 18:58 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Le 23/05/2019 à 19:27, Aaro Koskinen a écrit : > Hi, > > On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote: >> Ok, the Oops confirms that the error is due to executing the kexec control >> code which is located outside the kernel text area. >> >> My yesterday's proposed change doesn't work because on book3S/32, NX >> protection is based on setting segments to NX, and using IBATs for kernel >> text. >> >> Can you try the patch I sent out a few minutes ago ? >> (https://patchwork.ozlabs.org/patch/1103827/) > > It now crashes with "BUG: Unable to handle kernel instruction fetch" > and the faulting address is 0xef13a000. > Ok. Can you try with both changes at the same time, ie the mtsrin(...) and the change_page_attr() ? I suspect that allthough the HW is not able to check EXEC flag, the SW will check it before loading the hash entry. Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-23 18:58 ` Christophe Leroy @ 2019-05-23 22:23 ` Aaro Koskinen 2019-05-24 5:46 ` Christophe Leroy 0 siblings, 1 reply; 20+ messages in thread From: Aaro Koskinen @ 2019-05-23 22:23 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote: > Le 23/05/2019 à 19:27, Aaro Koskinen a écrit : > >On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote: > >>Ok, the Oops confirms that the error is due to executing the kexec control > >>code which is located outside the kernel text area. > >> > >>My yesterday's proposed change doesn't work because on book3S/32, NX > >>protection is based on setting segments to NX, and using IBATs for kernel > >>text. > >> > >>Can you try the patch I sent out a few minutes ago ? > >>(https://patchwork.ozlabs.org/patch/1103827/) > > > >It now crashes with "BUG: Unable to handle kernel instruction fetch" > >and the faulting address is 0xef13a000. > > Ok. > > Can you try with both changes at the same time, ie the mtsrin(...) and the > change_page_attr() ? > > I suspect that allthough the HW is not able to check EXEC flag, the SW will > check it before loading the hash entry. Unfortunately still no luck... The crash is pretty much the same with both changes. A. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-23 22:23 ` Aaro Koskinen @ 2019-05-24 5:46 ` Christophe Leroy 2019-05-24 6:08 ` Christophe Leroy 0 siblings, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 5:46 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Hi Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : > Hi, > > On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote: >> Le 23/05/2019 à 19:27, Aaro Koskinen a écrit : >>> On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote: >>>> Ok, the Oops confirms that the error is due to executing the kexec control >>>> code which is located outside the kernel text area. >>>> >>>> My yesterday's proposed change doesn't work because on book3S/32, NX >>>> protection is based on setting segments to NX, and using IBATs for kernel >>>> text. >>>> >>>> Can you try the patch I sent out a few minutes ago ? >>>> (https://patchwork.ozlabs.org/patch/1103827/) >>> >>> It now crashes with "BUG: Unable to handle kernel instruction fetch" >>> and the faulting address is 0xef13a000. >> >> Ok. >> >> Can you try with both changes at the same time, ie the mtsrin(...) and the >> change_page_attr() ? >> >> I suspect that allthough the HW is not able to check EXEC flag, the SW will >> check it before loading the hash entry. > > Unfortunately still no luck... The crash is pretty much the same with both > changes. Right. In fact change_page_attr() does nothing because this part of RAM is mapped by DBATs so v_block_mapped() returns not NULL. So, we have to set an IBAT for this area. I'll try and send you a new patch for that before noon (CET). Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-24 5:46 ` Christophe Leroy @ 2019-05-24 6:08 ` Christophe Leroy 2019-05-24 7:36 ` Aaro Koskinen 0 siblings, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 6:08 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Le 24/05/2019 à 07:46, Christophe Leroy a écrit : > Hi > > Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : >> Hi, >> >> On Thu, May 23, 2019 at 08:58:11PM +0200, Christophe Leroy wrote: >>> Le 23/05/2019 à 19:27, Aaro Koskinen a écrit : >>>> On Thu, May 23, 2019 at 07:33:38AM +0200, Christophe Leroy wrote: >>>>> Ok, the Oops confirms that the error is due to executing the kexec >>>>> control >>>>> code which is located outside the kernel text area. >>>>> >>>>> My yesterday's proposed change doesn't work because on book3S/32, NX >>>>> protection is based on setting segments to NX, and using IBATs for >>>>> kernel >>>>> text. >>>>> >>>>> Can you try the patch I sent out a few minutes ago ? >>>>> (https://patchwork.ozlabs.org/patch/1103827/) >>>> >>>> It now crashes with "BUG: Unable to handle kernel instruction fetch" >>>> and the faulting address is 0xef13a000. >>> >>> Ok. >>> >>> Can you try with both changes at the same time, ie the mtsrin(...) >>> and the >>> change_page_attr() ? >>> >>> I suspect that allthough the HW is not able to check EXEC flag, the >>> SW will >>> check it before loading the hash entry. >> >> Unfortunately still no luck... The crash is pretty much the same with >> both >> changes. > > Right. In fact change_page_attr() does nothing because this part of RAM > is mapped by DBATs so v_block_mapped() returns not NULL. > > So, we have to set an IBAT for this area. I'll try and send you a new > patch for that before noon (CET). > patch sent out. In the patch I have also added a printk to print the buffer address, so if the problem still occurs, we'll know if the problem is really at the address of the buffer or if we are wrong from the beginning. Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-24 6:08 ` Christophe Leroy @ 2019-05-24 7:36 ` Aaro Koskinen 2019-05-24 7:40 ` Christophe Leroy 0 siblings, 1 reply; 20+ messages in thread From: Aaro Koskinen @ 2019-05-24 7:36 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Fri, May 24, 2019 at 08:08:36AM +0200, Christophe Leroy wrote: > >Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : > >>Unfortunately still no luck... The crash is pretty much the same with > >>both > >>changes. > > > >Right. In fact change_page_attr() does nothing because this part of RAM is > >mapped by DBATs so v_block_mapped() returns not NULL. > > > >So, we have to set an IBAT for this area. I'll try and send you a new > >patch for that before noon (CET). > > > > patch sent out. In the patch I have also added a printk to print the buffer > address, so if the problem still occurs, we'll know if the problem is really > at the address of the buffer or if we are wrong from the beginning. Reboot code buffer at ef0c3000 Bye! BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xef0c3000 A. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-24 7:36 ` Aaro Koskinen @ 2019-05-24 7:40 ` Christophe Leroy 2019-05-24 13:29 ` Aaro Koskinen 0 siblings, 1 reply; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 7:40 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Le 24/05/2019 à 09:36, Aaro Koskinen a écrit : > Hi, > > On Fri, May 24, 2019 at 08:08:36AM +0200, Christophe Leroy wrote: >>> Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : >>>> Unfortunately still no luck... The crash is pretty much the same with >>>> both >>>> changes. >>> >>> Right. In fact change_page_attr() does nothing because this part of RAM is >>> mapped by DBATs so v_block_mapped() returns not NULL. >>> >>> So, we have to set an IBAT for this area. I'll try and send you a new >>> patch for that before noon (CET). >>> >> >> patch sent out. In the patch I have also added a printk to print the buffer >> address, so if the problem still occurs, we'll know if the problem is really >> at the address of the buffer or if we are wrong from the beginning. > > Reboot code buffer at ef0c3000 > Bye! > BUG: Unable to handle kernel instruction fetch > Faulting instruction address: 0xef0c3000 > Oops, I forgot to call update_bats() after setibat(). Can you add it and retry ? Thanks Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-24 7:40 ` Christophe Leroy @ 2019-05-24 13:29 ` Aaro Koskinen 2019-05-24 13:35 ` Christophe Leroy 0 siblings, 1 reply; 20+ messages in thread From: Aaro Koskinen @ 2019-05-24 13:29 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Fri, May 24, 2019 at 09:40:30AM +0200, Christophe Leroy wrote: > Le 24/05/2019 à 09:36, Aaro Koskinen a écrit : > >On Fri, May 24, 2019 at 08:08:36AM +0200, Christophe Leroy wrote: > >>>Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : > >>>>Unfortunately still no luck... The crash is pretty much the same with > >>>>both > >>>>changes. > >>> > >>>Right. In fact change_page_attr() does nothing because this part of RAM is > >>>mapped by DBATs so v_block_mapped() returns not NULL. > >>> > >>>So, we have to set an IBAT for this area. I'll try and send you a new > >>>patch for that before noon (CET). > >>> > >> > >>patch sent out. In the patch I have also added a printk to print the buffer > >>address, so if the problem still occurs, we'll know if the problem is really > >>at the address of the buffer or if we are wrong from the beginning. > > > >Reboot code buffer at ef0c3000 > >Bye! > >BUG: Unable to handle kernel instruction fetch > >Faulting instruction address: 0xef0c3000 > > > > Oops, I forgot to call update_bats() after setibat(). > > Can you add it and retry ? Thanks, that was it, now it finally works! A. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-24 13:29 ` Aaro Koskinen @ 2019-05-24 13:35 ` Christophe Leroy 0 siblings, 0 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 13:35 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev Le 24/05/2019 à 15:29, Aaro Koskinen a écrit : > Hi, > > On Fri, May 24, 2019 at 09:40:30AM +0200, Christophe Leroy wrote: >> Le 24/05/2019 à 09:36, Aaro Koskinen a écrit : >>> On Fri, May 24, 2019 at 08:08:36AM +0200, Christophe Leroy wrote: >>>>> Le 24/05/2019 à 00:23, Aaro Koskinen a écrit : >>>>>> Unfortunately still no luck... The crash is pretty much the same with >>>>>> both >>>>>> changes. >>>>> >>>>> Right. In fact change_page_attr() does nothing because this part of RAM is >>>>> mapped by DBATs so v_block_mapped() returns not NULL. >>>>> >>>>> So, we have to set an IBAT for this area. I'll try and send you a new >>>>> patch for that before noon (CET). >>>>> >>>> >>>> patch sent out. In the patch I have also added a printk to print the buffer >>>> address, so if the problem still occurs, we'll know if the problem is really >>>> at the address of the buffer or if we are wrong from the beginning. >>> >>> Reboot code buffer at ef0c3000 >>> Bye! >>> BUG: Unable to handle kernel instruction fetch >>> Faulting instruction address: 0xef0c3000 >>> >> >> Oops, I forgot to call update_bats() after setibat(). >> >> Can you add it and retry ? > > Thanks, that was it, now it finally works! > Thanks for reporting the issue and testing. I'll work on a clean fix patch in the begining of June. Christophe ^ permalink raw reply [flat|nested] 20+ messages in thread
* [RFC PATCH v2] powerpc: fix kexec failure on book3s/32 [not found] ` <20190522211724.GC456@darkstar.musicnaut.iki.fi> @ 2019-05-24 6:05 ` Christophe Leroy 2019-05-23 5:33 ` [BISECTED] kexec regression on PowerBook G4 Christophe Leroy 2019-05-24 6:05 ` Christophe Leroy 2 siblings, 0 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 6:05 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linux-kernel, linuxppc-dev Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- arch/powerpc/kernel/machine_kexec_32.c | 8 ++++++++ arch/powerpc/mm/book3s32/mmu.c | 7 +++++-- arch/powerpc/mm/mmu_decl.h | 2 ++ 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c index affe5dcce7f4..83e61a8f8468 100644 --- a/arch/powerpc/kernel/machine_kexec_32.c +++ b/arch/powerpc/kernel/machine_kexec_32.c @@ -15,6 +15,7 @@ #include <asm/cacheflush.h> #include <asm/hw_irq.h> #include <asm/io.h> +#include <mm/mmu_decl.h> typedef void (*relocate_new_kernel_t)( unsigned long indirection_page, @@ -35,6 +36,8 @@ void default_machine_kexec(struct kimage *image) unsigned long page_list; unsigned long reboot_code_buffer, reboot_code_buffer_phys; relocate_new_kernel_t rnk; + unsigned long bat_size = 128 << 10; + unsigned long bat_mask = ~(bat_size - 1); /* Interrupts aren't acceptable while we reboot */ local_irq_disable(); @@ -54,6 +57,11 @@ void default_machine_kexec(struct kimage *image) memcpy((void *)reboot_code_buffer, relocate_new_kernel, relocate_new_kernel_size); + printk(KERN_INFO "Reboot code buffer at %lx\n", reboot_code_buffer); + mtsrin(mfsrin(reboot_code_buffer) & ~SR_NX, reboot_code_buffer); + setibat(7, reboot_code_buffer & bat_mask, reboot_code_buffer_phys & bat_mask, + bat_size, PAGE_KERNEL_TEXT); + flush_icache_range(reboot_code_buffer, reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); printk(KERN_INFO "Bye!\n"); diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c index fc073cb2c517..7124700edb0f 100644 --- a/arch/powerpc/mm/book3s32/mmu.c +++ b/arch/powerpc/mm/book3s32/mmu.c @@ -124,8 +124,8 @@ static unsigned int block_size(unsigned long base, unsigned long top) * of 2 between 128k and 256M. * Only for 603+ ... */ -static void setibat(int index, unsigned long virt, phys_addr_t phys, - unsigned int size, pgprot_t prot) +void setibat(int index, unsigned long virt, phys_addr_t phys, + unsigned int size, pgprot_t prot) { unsigned int bl = (size >> 17) - 1; int wimgxpp; @@ -197,6 +197,9 @@ void mmu_mark_initmem_nx(void) if (cpu_has_feature(CPU_FTR_601)) return; + if (IS_ENABLED(CONFIG_KEXEC)) + nb--; + 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); diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h index 7bac0aa2026a..478584d50cf2 100644 --- a/arch/powerpc/mm/mmu_decl.h +++ b/arch/powerpc/mm/mmu_decl.h @@ -103,6 +103,8 @@ void print_system_hash_info(void); extern void mapin_ram(void); extern void setbat(int index, unsigned long virt, phys_addr_t phys, unsigned int size, pgprot_t prot); +void setibat(int index, unsigned long virt, phys_addr_t phys, + unsigned int size, pgprot_t prot); extern int __map_without_bats; extern unsigned int rtas_data, rtas_size; -- 2.13.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [RFC PATCH v2] powerpc: fix kexec failure on book3s/32 @ 2019-05-24 6:05 ` Christophe Leroy 0 siblings, 0 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 6:05 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev, linux-kernel Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- arch/powerpc/kernel/machine_kexec_32.c | 8 ++++++++ arch/powerpc/mm/book3s32/mmu.c | 7 +++++-- arch/powerpc/mm/mmu_decl.h | 2 ++ 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c index affe5dcce7f4..83e61a8f8468 100644 --- a/arch/powerpc/kernel/machine_kexec_32.c +++ b/arch/powerpc/kernel/machine_kexec_32.c @@ -15,6 +15,7 @@ #include <asm/cacheflush.h> #include <asm/hw_irq.h> #include <asm/io.h> +#include <mm/mmu_decl.h> typedef void (*relocate_new_kernel_t)( unsigned long indirection_page, @@ -35,6 +36,8 @@ void default_machine_kexec(struct kimage *image) unsigned long page_list; unsigned long reboot_code_buffer, reboot_code_buffer_phys; relocate_new_kernel_t rnk; + unsigned long bat_size = 128 << 10; + unsigned long bat_mask = ~(bat_size - 1); /* Interrupts aren't acceptable while we reboot */ local_irq_disable(); @@ -54,6 +57,11 @@ void default_machine_kexec(struct kimage *image) memcpy((void *)reboot_code_buffer, relocate_new_kernel, relocate_new_kernel_size); + printk(KERN_INFO "Reboot code buffer at %lx\n", reboot_code_buffer); + mtsrin(mfsrin(reboot_code_buffer) & ~SR_NX, reboot_code_buffer); + setibat(7, reboot_code_buffer & bat_mask, reboot_code_buffer_phys & bat_mask, + bat_size, PAGE_KERNEL_TEXT); + flush_icache_range(reboot_code_buffer, reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); printk(KERN_INFO "Bye!\n"); diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c index fc073cb2c517..7124700edb0f 100644 --- a/arch/powerpc/mm/book3s32/mmu.c +++ b/arch/powerpc/mm/book3s32/mmu.c @@ -124,8 +124,8 @@ static unsigned int block_size(unsigned long base, unsigned long top) * of 2 between 128k and 256M. * Only for 603+ ... */ -static void setibat(int index, unsigned long virt, phys_addr_t phys, - unsigned int size, pgprot_t prot) +void setibat(int index, unsigned long virt, phys_addr_t phys, + unsigned int size, pgprot_t prot) { unsigned int bl = (size >> 17) - 1; int wimgxpp; @@ -197,6 +197,9 @@ void mmu_mark_initmem_nx(void) if (cpu_has_feature(CPU_FTR_601)) return; + if (IS_ENABLED(CONFIG_KEXEC)) + nb--; + 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); diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h index 7bac0aa2026a..478584d50cf2 100644 --- a/arch/powerpc/mm/mmu_decl.h +++ b/arch/powerpc/mm/mmu_decl.h @@ -103,6 +103,8 @@ void print_system_hash_info(void); extern void mapin_ram(void); extern void setbat(int index, unsigned long virt, phys_addr_t phys, unsigned int size, pgprot_t prot); +void setibat(int index, unsigned long virt, phys_addr_t phys, + unsigned int size, pgprot_t prot); extern int __map_without_bats; extern unsigned int rtas_data, rtas_size; -- 2.13.3 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [RFC PATCH v2] powerpc: fix kexec failure on book3s/32 2019-05-24 6:05 ` Christophe Leroy (?) @ 2019-05-24 13:38 ` Christophe Leroy -1 siblings, 0 replies; 20+ messages in thread From: Christophe Leroy @ 2019-05-24 13:38 UTC (permalink / raw) To: Aaro Koskinen; +Cc: linuxppc-dev, linux-kernel Le 24/05/2019 à 08:05, Christophe Leroy a écrit : > Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX") > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> > --- > arch/powerpc/kernel/machine_kexec_32.c | 8 ++++++++ > arch/powerpc/mm/book3s32/mmu.c | 7 +++++-- > arch/powerpc/mm/mmu_decl.h | 2 ++ > 3 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/arch/powerpc/kernel/machine_kexec_32.c b/arch/powerpc/kernel/machine_kexec_32.c > index affe5dcce7f4..83e61a8f8468 100644 > --- a/arch/powerpc/kernel/machine_kexec_32.c > +++ b/arch/powerpc/kernel/machine_kexec_32.c > @@ -15,6 +15,7 @@ > #include <asm/cacheflush.h> > #include <asm/hw_irq.h> > #include <asm/io.h> > +#include <mm/mmu_decl.h> > > typedef void (*relocate_new_kernel_t)( > unsigned long indirection_page, > @@ -35,6 +36,8 @@ void default_machine_kexec(struct kimage *image) > unsigned long page_list; > unsigned long reboot_code_buffer, reboot_code_buffer_phys; > relocate_new_kernel_t rnk; > + unsigned long bat_size = 128 << 10; > + unsigned long bat_mask = ~(bat_size - 1); > > /* Interrupts aren't acceptable while we reboot */ > local_irq_disable(); > @@ -54,6 +57,11 @@ void default_machine_kexec(struct kimage *image) > memcpy((void *)reboot_code_buffer, relocate_new_kernel, > relocate_new_kernel_size); > > + printk(KERN_INFO "Reboot code buffer at %lx\n", reboot_code_buffer); > + mtsrin(mfsrin(reboot_code_buffer) & ~SR_NX, reboot_code_buffer); > + setibat(7, reboot_code_buffer & bat_mask, reboot_code_buffer_phys & bat_mask, > + bat_size, PAGE_KERNEL_TEXT); A call to update_bats() have to be added here after setibat() Christophe > + > flush_icache_range(reboot_code_buffer, > reboot_code_buffer + KEXEC_CONTROL_PAGE_SIZE); > printk(KERN_INFO "Bye!\n"); > diff --git a/arch/powerpc/mm/book3s32/mmu.c b/arch/powerpc/mm/book3s32/mmu.c > index fc073cb2c517..7124700edb0f 100644 > --- a/arch/powerpc/mm/book3s32/mmu.c > +++ b/arch/powerpc/mm/book3s32/mmu.c > @@ -124,8 +124,8 @@ static unsigned int block_size(unsigned long base, unsigned long top) > * of 2 between 128k and 256M. > * Only for 603+ ... > */ > -static void setibat(int index, unsigned long virt, phys_addr_t phys, > - unsigned int size, pgprot_t prot) > +void setibat(int index, unsigned long virt, phys_addr_t phys, > + unsigned int size, pgprot_t prot) > { > unsigned int bl = (size >> 17) - 1; > int wimgxpp; > @@ -197,6 +197,9 @@ void mmu_mark_initmem_nx(void) > if (cpu_has_feature(CPU_FTR_601)) > return; > > + if (IS_ENABLED(CONFIG_KEXEC)) > + nb--; > + > 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); > diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h > index 7bac0aa2026a..478584d50cf2 100644 > --- a/arch/powerpc/mm/mmu_decl.h > +++ b/arch/powerpc/mm/mmu_decl.h > @@ -103,6 +103,8 @@ void print_system_hash_info(void); > extern void mapin_ram(void); > extern void setbat(int index, unsigned long virt, phys_addr_t phys, > unsigned int size, pgprot_t prot); > +void setibat(int index, unsigned long virt, phys_addr_t phys, > + unsigned int size, pgprot_t prot); > > extern int __map_without_bats; > extern unsigned int rtas_data, rtas_size; > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [BISECTED] kexec regression on PowerBook G4 2019-05-22 6:14 ` Christophe Leroy 2019-05-22 7:44 ` Christophe Leroy @ 2019-05-22 20:07 ` Aaro Koskinen 1 sibling, 0 replies; 20+ messages in thread From: Aaro Koskinen @ 2019-05-22 20:07 UTC (permalink / raw) To: Christophe Leroy; +Cc: linuxppc-dev Hi, On Wed, May 22, 2019 at 08:14:23AM +0200, Christophe Leroy wrote: > Le 22/05/2019 à 00:18, Aaro Koskinen a écrit : > >I was trying to upgrade from v5.0 -> v5.1 on PowerBook G4, but when trying > >to kexec a kernel the system gets stuck (no errors seen on the console). > > Do you mean you are trying to kexec a v5.1 kernel from a v5.0 kernel, or do > you have a working v5.1 kernel, but kexec doesn't work with it ? To summarize, my system's boot goes like this: Open Firmware -> kernel A (small due to OF limit) -> (kexec) -> kernel B (big) First both A & B were at v5.0 ==> boot works. Then I upgraded B to v5.1 ==> boot works. Then I upgraded A to v5.1 ==> boot fails. So the issue must be in A. So after bisecting I got the following result: Kernel A with commit 93c4a162b014 ==> fails Kernel A with commit 93c4a162b014^1 ==> works n >Bisected to: 93c4a162b014 ("powerpc/6xx: Store PGDIR physical address > >in a SPRG"). This commit doesn't revert cleanly anymore but I tested > >that the one before works OK. > > Not sure that's the problem. There was a problem with that commit, but it > was fixed by 4622a2d43101 ("powerpc/6xx: fix setup and use of > SPRN_SPRG_PGDIR for hash32"). > You probably hit some commit between those two during bisect, that's likely > the reason why you ended here. > > Can you restart your bisect from 4622a2d43101 ? This is not a good commit to start with, as it already gives "kernel tried to execute exec protected page..." after the "Bye!" message. > If you have CONFIG_SMP, maybe you should also consider taking 397d2300b08c > ("powerpc/32s: fix flush_hash_pages() on SMP"). Stable 5.1.4 includes it. This is UP computer and CONFIG_SMP is not set. > >With current Linus HEAD (9c7db5004280), it gets a bit further but still > >doesn't work: now I get an error on the console after kexec "Starting > >new kernel! ... Bye!": > > > > kernel tried to execute exec-protected page (...) - exploit attempt? > > Interesting. > > Do you have CONFIG_STRICT_KERNEL_RWX=y in your .config ? If so, can you > retry without it ? I don't set that option. A. ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-05-24 13:39 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-21 22:18 [BISECTED] kexec regression on PowerBook G4 Aaro Koskinen
2019-05-22 6:14 ` Christophe Leroy
2019-05-22 7:44 ` Christophe Leroy
2019-05-22 20:13 ` Aaro Koskinen
2019-05-22 20:33 ` LEROY Christophe
[not found] ` <20190522211724.GC456@darkstar.musicnaut.iki.fi>
2019-05-23 5:24 ` [RFC PATCH] powerpc: fix kexec failure on book3s/32 Christophe Leroy
2019-05-23 5:33 ` [BISECTED] kexec regression on PowerBook G4 Christophe Leroy
2019-05-23 17:27 ` Aaro Koskinen
2019-05-23 18:58 ` Christophe Leroy
2019-05-23 22:23 ` Aaro Koskinen
2019-05-24 5:46 ` Christophe Leroy
2019-05-24 6:08 ` Christophe Leroy
2019-05-24 7:36 ` Aaro Koskinen
2019-05-24 7:40 ` Christophe Leroy
2019-05-24 13:29 ` Aaro Koskinen
2019-05-24 13:35 ` Christophe Leroy
2019-05-24 6:05 ` [RFC PATCH v2] powerpc: fix kexec failure on book3s/32 Christophe Leroy
2019-05-24 6:05 ` Christophe Leroy
2019-05-24 13:38 ` Christophe Leroy
2019-05-22 20:07 ` [BISECTED] kexec regression on PowerBook G4 Aaro Koskinen
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.