Thread (4 messages) 4 messages, 3 authors, 2026-08-20

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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help