Re: [BUG] powerpc: userspace processes crash in ld64.so.2 when running recent linux-next kernels
flat view
From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Date: 2026-08-20 03:02:27
Also in:
linux-mm, lkml
Subsystem:
linux for powerpc (32-bit and 64-bit), the rest · Maintainers:
Madhavan Srinivasan, Linus Torvalds
"Christophe Leroy (CS GROUP)" [off-list ref] writes:
Le 11/08/2026 à 06:23, Venkat Rao Bagalkote a écrit :quoted
As part of debugging and suggested by Maddy, I reverted the following commit: 263e5159e00a ("powerpc: Fix exit_flags field placement in pt_regs for ptrace") and rebuilt/booted linux-next with only that change reverted. After booting the reverted kernel, I rebuilt the latest upstream kernel using the same userspace and toolchain. The build completed successfully and I did not observe any of the ld64.so.2 userspace segfaults that were previously seen during kernel compilation. Kernel used for testing: 7.2.0-rc5-next-20260731-00001-g79d9c1ce90a9 Top of tree: commit 79d9c1ce90a9873422ca4d6d0124a1d1c10a098c Revert "powerpc: Fix exit_flags field placement in pt_regs for ptrace" The upstream kernel build completed successfully: INSTALL /lib/modules/7.2.0-rc7/kernel/net/openvswitch/vport-gre.ko DEPMOD /lib/modules/7.2.0-rc7 INSTALL /boot Based on this testing, reverting commit 263e5159e00a appears to eliminate the random userspace crashes observed during kernel builds, suggesting that the issue may be related to that change.But commit 263e5159e00a fixes commit d7a6797e0bc1 ("powerpc: add exit_flags field in pt_regs"), by reverting commit 263e5159e00a you re-introduce other bugs. It's a bit difficult to see what commit 263e5159e00a is doing exactly, most of it is a revert of commit d7a6797e0bc1 but it does something instead. Need to see what remains with both commits applied.
Looking at the diff - I had shared a diff internally with Venkat. Thought of doing the same here too. This seems to be holding up for him in his internal testing. I haven't fully gone through this path yet to send an official patch - but hopefully will do that soon! syscall_exit_prepare() record _TIF_RESTOREALL value in exit_result, but if for some reason (e.g. like an interrupt pending), if we go via syscall_exit_restart(), then we are returning ret from here and loosing the _TIF_RESTOREALL value which was captured earlier. So instead I believe we should return regs->exit_result from here. I see that we were returning exit_result prior to the culprit patch.
diff --git a/arch/powerpc/kernel/interrupt.c b/arch/powerpc/kernel/interrupt.c
index 5b88bf72786c..bf167a41a820 100644
--- a/arch/powerpc/kernel/interrupt.c
+++ b/arch/powerpc/kernel/interrupt.c@@ -175,7 +175,13 @@ notrace unsigned long syscall_exit_restart(unsigned long r3, struct pt_regs *reg current_thread_info()->exit_flags &= ~_TIF_RESTOREALL; regs->exit_result |= ret; - return ret; + return regs->exit_result; } #endif -ritesh