Re: [PATCH RFC POC 09/50] m68k: commit fds on syscall exit

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] m68k: single-step SIGTRAP lost on fd-allocating syscalls
--

commit 731b1387fc76d92d165ee1f28de694e3d228627b
Author: Christian Brauner <brauner@xxxxxxxxxx>

m68k: commit fds on syscall exit

Add TIF_FD_SLOTS and test it on the untraced return from a system
call in all three entry paths. A task that reserved descriptors calls
syscall_trace_leave(), which commits them before the ptrace exit stop.

[ ... ]

> diff --git a/arch/m68k/kernel/entry.S b/arch/m68k/kernel/entry.S
> index 338b474910f74..9e4471f681652 100644
> --- a/arch/m68k/kernel/entry.S
> +++ b/arch/m68k/kernel/entry.S
> @@ -229,6 +229,8 @@ ret_from_syscall:
>  syscall_exit_work:
>  	btst	#5,%sp@(PT_OFF_SR)	| check if returning to kernel
>  	bnes	1b			| if so, skip resched, signals
> +	btst	#4,%a1@(TINFO_FLAGS+2)	| TIF_FD_SLOTS: commit descriptors
> +	jne	do_trace_exit

[Severity: High]
Does this new branch cause delayed trace (single-step) SIGTRAPs to be lost? 

If a process is being single-stepped (TIF_DELAYED_TRACE is set) and executes a 
syscall that allocates file descriptors (TIF_FD_SLOTS is set), this 
unconditionally branches to do_trace_exit. 

Looking at do_trace_exit, it executes syscall_trace_leave() and then directly
jumps to the exception return path, bypassing the jmi do_delayed_trace logic 
completely. 

This means single-stepping over a system call like open() could fail to 
deliver the expected SIGTRAP, which might break debugger functionality.

>  	lslw	#1,%d0
>  	jcs	do_trace_exit
>  	jmi	do_delayed_trace

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260915-work-fd-reserve-unify-folded-v1-0-4d5217d6b246@xxxxxxxxxx?part=9