Re: [BUG] powerpc: userspace processes crash in ld64.so.2 when running recent linux-next kernels

[IBM]

"Christophe Leroy (CS GROUP)" <chleroy@xxxxxxxxxx> writes:

> Le 11/08/2026 à 06:23, Venkat Rao Bagalkote a écrit :
>> 
>> 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