Build failure in v4.4.y.queue (ppc:allmodconfig)

Build failure in v4.4.y.queue (ppc:allmodconfig)

[Guenter Roeck]

I see multiple instances of:

arch/powerpc/kernel/exceptions-64s.S:839: Error:
	attempt to move .org backwards

in v4.4.y.queue (v4.4.179-143-gc4db218e9451).

This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
forwarding barrier at kernel entry/exit"), which is part of a large patch
series and can not easily be reverted.

Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?

Thanks,
Guenter

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Greg Kroah-Hartman]

On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> I see multiple instances of:
> 
> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> 	attempt to move .org backwards
> 
> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> 
> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> forwarding barrier at kernel entry/exit"), which is part of a large patch
> series and can not easily be reverted.
> 
> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?

Michael, I thought this patch series was supposed to fix ppc issues, not
add to them :)

Any ideas on what to do here?

thanks,

greg k-h

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Michal Suchánek]

On Thu, 9 May 2019 08:53:24 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> > I see multiple instances of:
> > 
> > arch/powerpc/kernel/exceptions-64s.S:839: Error:
> > 	attempt to move .org backwards
> > 
> > in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> > 
> > This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> > forwarding barrier at kernel entry/exit"), which is part of a large patch
> > series and can not easily be reverted.
> > 
> > Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?  
> 
> Michael, I thought this patch series was supposed to fix ppc issues, not
> add to them :)
> 
> Any ideas on what to do here?

What exact code do you build?

In my source there the SLB relon handler starts just above this line and
a lot of out-ouf-line are handlers before. Moving some out-of-line
handlers below the parts with fixed location should fix the build error.

Thanks

Michal

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Guenter Roeck]

On 5/9/19 2:49 AM, Michal Suchánek wrote:
> On Thu, 9 May 2019 08:53:24 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> 
>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>>> I see multiple instances of:
>>>
>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>>> 	attempt to move .org backwards
>>>
>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>>
>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>>> series and can not easily be reverted.
>>>
>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>>
>> Michael, I thought this patch series was supposed to fix ppc issues, not
>> add to them :)
>>
>> Any ideas on what to do here?
> 
> What exact code do you build?
>
$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
$ powerpc64-linux-gcc --version
powerpc64-linux-gcc (GCC) 8.3.0

Guenter

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Michal Suchánek]

On Thu, 9 May 2019 06:07:31 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 5/9/19 2:49 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 08:53:24 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >   
> >> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:  
> >>> I see multiple instances of:
> >>>
> >>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >>> 	attempt to move .org backwards
> >>>
> >>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >>>
> >>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> >>> forwarding barrier at kernel entry/exit"), which is part of a large patch
> >>> series and can not easily be reverted.
> >>>
> >>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?  
> >>
> >> Michael, I thought this patch series was supposed to fix ppc issues, not
> >> add to them :)
> >>
> >> Any ideas on what to do here?  
> > 
> > What exact code do you build?
> >  
> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
> $ powerpc64-linux-gcc --version
> powerpc64-linux-gcc (GCC) 8.3.0
>

Gcc should not see this file. I am asking because I do not see an .org
directive at line 839 of 4.4.179. I probably need some different repo
or extra patches to see the same code as you do.

Thanks

Michal

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Guenter Roeck]

On 5/9/19 6:26 AM, Michal Suchánek wrote:
> On Thu, 9 May 2019 06:07:31 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
> 
>> On 5/9/19 2:49 AM, Michal Suchánek wrote:
>>> On Thu, 9 May 2019 08:53:24 +0200
>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>>>    
>>>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>>>>> I see multiple instances of:
>>>>>
>>>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>>>>> 	attempt to move .org backwards
>>>>>
>>>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>>>>>
>>>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>>>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>>>>> series and can not easily be reverted.
>>>>>
>>>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>>>>
>>>> Michael, I thought this patch series was supposed to fix ppc issues, not
>>>> add to them :)
>>>>
>>>> Any ideas on what to do here?
>>>
>>> What exact code do you build?
>>>   
>> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
>> $ powerpc64-linux-gcc --version
>> powerpc64-linux-gcc (GCC) 8.3.0
>>
> 
> Gcc should not see this file. I am asking because I do not see an .org
> directive at line 839 of 4.4.179. I probably need some different repo
> or extra patches to see the same code as you do.
> 
v4.4.179-143-gc4db218e9451 from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
branch linux-4.4.y

That also includes 'powerpc/64s: Improve RFI L1-D cache flush fallback',
but reverting it does not make a difference. Also, the .org is
hidden in STD_RELON_EXCEPTION_PSERIES().

Guenter

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Michal Suchánek]

On Thu, 9 May 2019 07:06:32 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> On 5/9/19 6:26 AM, Michal Suchánek wrote:
> > On Thu, 9 May 2019 06:07:31 -0700
> > Guenter Roeck <linux@roeck-us.net> wrote:
> >   
> >> On 5/9/19 2:49 AM, Michal Suchánek wrote:  
> >>> On Thu, 9 May 2019 08:53:24 +0200
> >>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >>>      
> >>>> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:  
> >>>>> I see multiple instances of:
> >>>>>
> >>>>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >>>>> 	attempt to move .org backwards
> >>>>>
> >>>>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >>>>>
> >>>>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> >>>>> forwarding barrier at kernel entry/exit"), which is part of a large patch
> >>>>> series and can not easily be reverted.
> >>>>>
> >>>>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?  
> >>>>
> >>>> Michael, I thought this patch series was supposed to fix ppc issues, not
> >>>> add to them :)
> >>>>
> >>>> Any ideas on what to do here?  
> >>>
> >>> What exact code do you build?
> >>>     
> >> $ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux- allmodconfig
> >> $ powerpc64-linux-gcc --version
> >> powerpc64-linux-gcc (GCC) 8.3.0
> >>  
> > 
> > Gcc should not see this file. I am asking because I do not see an .org
> > directive at line 839 of 4.4.179. I probably need some different repo
> > or extra patches to see the same code as you do.
> >   
> v4.4.179-143-gc4db218e9451 from
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> branch linux-4.4.y

Still don't see it. That branch is at 4.4.179 and c4db218e9451 does not
exist after fetching from the repo.

Anyway, here is a patch (untested):

Subject: [PATCH] Move out-of-line exception handlers after relon exception
 handlers.

The relon exception handlers need to be at specific location and code
inflation in the common handler code can cause

Error: attempt to move .org backwards

Signed-off-by: Michal Suchanek <msuchanek@suse.de>
---
 arch/powerpc/kernel/exceptions-64s.S | 88 ++++++++++++++--------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 938a30fef031..1d477d21ff09 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -772,50 +772,6 @@ kvmppc_skip_Hinterrupt:
 	b	.
 #endif
 
-/*
- * Code from here down to __end_handlers is invoked from the
- * exception prologs above.  Because the prologs assemble the
- * addresses of these handlers using the LOAD_HANDLER macro,
- * which uses an ori instruction, these handlers must be in
- * the first 64k of the kernel image.
- */
-
-/*** Common interrupt handlers ***/
-
-	STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception)
-
-	STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
-	STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt)
-	STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt)
-#ifdef CONFIG_PPC_DOORBELL
-	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception)
-#else
-	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception)
-#endif
-	STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception)
-	STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception)
-	STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception)
-	STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt)
-	STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception)
-#ifdef CONFIG_PPC_DOORBELL
-	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception)
-#else
-	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception)
-#endif
-	STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception)
-	STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception)
-	STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception)
-#ifdef CONFIG_ALTIVEC
-	STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception)
-#else
-	STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception)
-#endif
-#ifdef CONFIG_CBE_RAS
-	STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
-	STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
-	STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
-#endif /* CONFIG_CBE_RAS */
-
 	/*
 	 * Relocation-on interrupts: A subset of the interrupts can be delivered
 	 * with IR=1/DR=1, if AIL==2 and MSR.HV won't be changed by delivering
@@ -969,6 +925,50 @@ system_call_entry:
 ppc64_runlatch_on_trampoline:
 	b	__ppc64_runlatch_on
 
+/*
+ * Code from here down to __end_handlers is invoked from the
+ * exception prologs above.  Because the prologs assemble the
+ * addresses of these handlers using the LOAD_HANDLER macro,
+ * which uses an ori instruction, these handlers must be in
+ * the first 64k of the kernel image.
+ */
+
+/*** Common interrupt handlers ***/
+
+	STD_EXCEPTION_COMMON(0x100, system_reset, system_reset_exception)
+
+	STD_EXCEPTION_COMMON_ASYNC(0x500, hardware_interrupt, do_IRQ)
+	STD_EXCEPTION_COMMON_ASYNC(0x900, decrementer, timer_interrupt)
+	STD_EXCEPTION_COMMON(0x980, hdecrementer, hdec_interrupt)
+#ifdef CONFIG_PPC_DOORBELL
+	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, doorbell_exception)
+#else
+	STD_EXCEPTION_COMMON_ASYNC(0xa00, doorbell_super, unknown_exception)
+#endif
+	STD_EXCEPTION_COMMON(0xb00, trap_0b, unknown_exception)
+	STD_EXCEPTION_COMMON(0xd00, single_step, single_step_exception)
+	STD_EXCEPTION_COMMON(0xe00, trap_0e, unknown_exception)
+	STD_EXCEPTION_COMMON(0xe40, emulation_assist, emulation_assist_interrupt)
+	STD_EXCEPTION_COMMON_ASYNC(0xe60, hmi_exception, handle_hmi_exception)
+#ifdef CONFIG_PPC_DOORBELL
+	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, doorbell_exception)
+#else
+	STD_EXCEPTION_COMMON_ASYNC(0xe80, h_doorbell, unknown_exception)
+#endif
+	STD_EXCEPTION_COMMON_ASYNC(0xf00, performance_monitor, performance_monitor_exception)
+	STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, instruction_breakpoint_exception)
+	STD_EXCEPTION_COMMON(0x1502, denorm, unknown_exception)
+#ifdef CONFIG_ALTIVEC
+	STD_EXCEPTION_COMMON(0x1700, altivec_assist, altivec_assist_exception)
+#else
+	STD_EXCEPTION_COMMON(0x1700, altivec_assist, unknown_exception)
+#endif
+#ifdef CONFIG_CBE_RAS
+	STD_EXCEPTION_COMMON(0x1200, cbe_system_error, cbe_system_error_exception)
+	STD_EXCEPTION_COMMON(0x1600, cbe_maintenance, cbe_maintenance_exception)
+	STD_EXCEPTION_COMMON(0x1800, cbe_thermal, cbe_thermal_exception)
+#endif /* CONFIG_CBE_RAS */
+
 /*
  * Here r13 points to the paca, r9 contains the saved CR,
  * SRR0 and SRR1 are saved in r11 and r12,
-- 
2.20.1

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Michael Ellerman]

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>> I see multiple instances of:
>> 
>> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>> 	attempt to move .org backwards
>> 
>> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>> 
>> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>> forwarding barrier at kernel entry/exit"), which is part of a large patch
>> series and can not easily be reverted.
>> 
>> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>
> Michael, I thought this patch series was supposed to fix ppc issues, not
> add to them :)

Well it fixes some, but creates others :}

> Any ideas on what to do here?

Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is
sufficient to get it building. Is that an option for your build tests
Guenter?

We can try to rearrange some of the exception vectors as Michal
suggested, but that's not without risk either.

cheers

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Guenter Roeck]

On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> > On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
> >> I see multiple instances of:
> >> 
> >> arch/powerpc/kernel/exceptions-64s.S:839: Error:
> >> 	attempt to move .org backwards
> >> 
> >> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
> >> 
> >> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
> >> forwarding barrier at kernel entry/exit"), which is part of a large patch
> >> series and can not easily be reverted.
> >> 
> >> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
> >
> > Michael, I thought this patch series was supposed to fix ppc issues, not
> > add to them :)
> 
> Well it fixes some, but creates others :}
> 
> > Any ideas on what to do here?
> 
> Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is
> sufficient to get it building. Is that an option for your build tests
> Guenter?
> 
I could turn it off unconditionally, meaning it would affect all other
branches. I would rather stop building ppc:allmodconfig for v4.4.y.

Guenter

Re: Build failure in v4.4.y.queue (ppc:allmodconfig)

[Michael Ellerman]

Guenter Roeck <linux@roeck-us.net> writes:
> On Fri, May 10, 2019 at 12:31:05AM +1000, Michael Ellerman wrote:
>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
>> > On Wed, May 08, 2019 at 01:26:42PM -0700, Guenter Roeck wrote:
>> >> I see multiple instances of:
>> >> 
>> >> arch/powerpc/kernel/exceptions-64s.S:839: Error:
>> >> 	attempt to move .org backwards
>> >> 
>> >> in v4.4.y.queue (v4.4.179-143-gc4db218e9451).
>> >> 
>> >> This is due to commit 9b2d4e06d7f1 ("powerpc/64s: Add support for a store
>> >> forwarding barrier at kernel entry/exit"), which is part of a large patch
>> >> series and can not easily be reverted.
>> >> 
>> >> Guess I'll stop doing ppc:allmodconfig builds in v4.4.y ?
>> >
>> > Michael, I thought this patch series was supposed to fix ppc issues, not
>> > add to them :)
>> 
>> Well it fixes some, but creates others :}
>> 
>> > Any ideas on what to do here?
>> 
>> Turning off CONFIG_CBE_RAS (obscure IBM Cell Blade RAS features) is
>> sufficient to get it building. Is that an option for your build tests
>> Guenter?
>> 
> I could turn it off unconditionally, meaning it would affect all other
> branches. I would rather stop building ppc:allmodconfig for v4.4.y.

Yeah fine by me. No one actually runs allmodconfig anyway.

cheers