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

Ritesh Harjani (IBM) <[email protected]>
Newsgroups org.ozlabs.lists.linuxppc-dev,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>
"Christophe Leroy (CS GROUP)" <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.