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@kernel-bugs.osdl.org
Reporter: erhard_f@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@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@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 [off-list ref]
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@vger.kernel.org # 4.13+
Signed-off-by: Michael Neuling [off-list ref]
Reviewed-by: Nicholas Piggin [off-list ref]
Reviewed-by: Christophe Leroy [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
Signed-off-by: Sasha Levin [off-list ref]
--
You are receiving this mail because:
You are watching the assignee of the bug.
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@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@kernel-bugs.osdl.org
Reporter: erhard_f@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@f0000000/ATY,AlteracParent@10/ATY,Alterac_B@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 [off-list ref]
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@vger.kernel.org # 4.13+
Signed-off-by: Michael Neuling [off-list ref]
Reviewed-by: Nicholas Piggin [off-list ref]
Reviewed-by: Christophe Leroy [off-list ref]
Signed-off-by: Michael Ellerman [off-list ref]
Signed-off-by: Sasha Levin [off-list ref]
On Tue, May 14, 2019 at 06:56:03AM +0200, Christophe Leroy wrote:
Hi Greg,
Could you please apply b45ba4a51cde29b2939365ef0c07ad34c8321789 to 4.9 since
51c3c62b58b357e8d35e4cc32f7b4ec907426fe3 was applied allthought marked for
#4.13+
It does not apply there (nor to the 4.4.y queue, which will need it as
well), so can you provide a working backport so that I can queue it up?
thanks,
greg k-h
Your fix landed in 4.9.177 and I can confirm my G4 boots fine now. Thanks!
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=203597
Michael Ellerman (michael@ellerman.id.au) changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
CC| |michael@ellerman.id.au
--
You are receiving this mail because:
You are watching the assignee of the bug.