[Bug 203597] New: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage

[Christophe Leroy]

Hi Greg,

Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9 
since 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought 
marked for #4.13+

Thanks
Christophe

Le 13/05/2019 à 22:18, bugzilla-daemon at bugzilla.kernel.org a écrit :
> https://bugzilla.kernel.org/show_bug.cgi?id=203597
> 
>              Bug ID: 203597
>             Summary: kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at
>                      early stage
>             Product: Platform Specific/Hardware
>             Version: 2.5
>      Kernel Version: 4.9.175
>            Hardware: PPC-32
>                  OS: Linux
>                Tree: Mainline
>              Status: NEW
>            Severity: normal
>            Priority: P1
>           Component: PPC-32
>            Assignee: platform_ppc-32 at kernel-bugs.osdl.org
>            Reporter: erhard_f at mailbox.org
>          Regression: No
> 
> Created attachment 282743
>    --> https://bugzilla.kernel.org/attachment.cgi?id=282743&action=edit
> kernel .config (PowerMac G4 MDD)
> 
> Trying out older kernels on the G4 MDD I noticed recent 4.9.x freeze the
> machine. Only message displayed in black letters on a white screen:
> 
> done
> found display   : /pco at f0000000/ATY,AlteracParent at 10/ATY,Alterac_B at 1,
> opening...
> 
> 
> It's a hard freeze, RCU_CPU_STALL_TIMEOUT does not kick in.
> 
> Tried other stable kernels, which all worked:
> 4.19.37
> 4.14.114
> 4.4.179
> 
> So I suppose it's only a 4.9.x issue. Last working 4.9.x kernel I had in
> service was 4.9.161. First one I spotted freezing was 4.9.171. A bisect gave me
> the following commit:
> 
> 1c38a84d45862be06ac418618981631eddbda741 is the first bad commit
> commit 1c38a84d45862be06ac418618981631eddbda741
> Author: Michael Neuling <mikey at neuling.org>
> Date:   Thu Apr 11 21:45:59 2019 +1000
> 
>      powerpc: Avoid code patching freed init sections
> 
>      commit 51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 upstream.
> 
>      This stops us from doing code patching in init sections after they've
>      been freed.
> 
>      In this chain:
>        kvm_guest_init() ->
>          kvm_use_magic_page() ->
>            fault_in_pages_readable() ->
>               __get_user() ->
>                 __get_user_nocheck() ->
>                   barrier_nospec();
> 
>      We have a code patching location at barrier_nospec() and
>      kvm_guest_init() is an init function. This whole chain gets inlined,
>      so when we free the init section (hence kvm_guest_init()), this code
>      goes away and hence should no longer be patched.
> 
>      We seen this as userspace memory corruption when using a memory
>      checker while doing partition migration testing on powervm (this
>      starts the code patching post migration via
>      /sys/kernel/mobility/migration). In theory, it could also happen when
>      using /sys/kernel/debug/powerpc/barrier_nospec.
> 
>      Cc: stable at vger.kernel.org # 4.13+
>      Signed-off-by: Michael Neuling <mikey at neuling.org>
>      Reviewed-by: Nicholas Piggin <npiggin at gmail.com>
>      Reviewed-by: Christophe Leroy <christophe.leroy at c-s.fr>
>      Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
>      Signed-off-by: Sasha Levin <sashal at kernel.org>
>