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 <[email protected]> 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-4d5217d6b...@kernel.org?part=9
