Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] xtensa: inconsistent mid-syscall ptrace exit tracing due to stale flags --
commit f64c69fbd6ff1a2ee8dd26645f9d56d2d371647e Author: Christian Brauner <[email protected]> xtensa: commit fds on syscall exit Add TIF_FD_SLOTS and test it once the system call has stored its return value. A task that reserved descriptors uses the traced path. [ ... ] > diff --git a/arch/xtensa/kernel/entry.S b/arch/xtensa/kernel/entry.S > index 272fff587907f..4b95f48736e6b 100644 > --- a/arch/xtensa/kernel/entry.S > +++ b/arch/xtensa/kernel/entry.S > @@ -1976,6 +1976,11 @@ ENTRY(system_call) > 1: /* regs->areg[2] = return_value */ > > s32i abi_rv, abi_saved0, PT_AREG2 > + > + /* descriptors reserved by the syscall are committed in > do_syscall_trace_leave */ > + GET_THREAD_INFO(a4, a1) > + l32i a4, a4, TI_FLAGS > + bbsi.l a4, TIF_FD_SLOTS, 1f > bnez abi_saved1, 1f [Severity: Medium] Does this introduce a regression leading to inconsistent ptrace observability? The exit path in system_call() dynamically checks TIF_FD_SLOTS from fresh thread flags (loaded into a4), but falls back to abi_saved1 for trace work. Earlier in system_call(), abi_saved1 is cached before executing the syscall: GET_THREAD_INFO(a4, a1) l32i abi_saved1, a4, TI_FLAGS movi a4, _TIF_WORK_MASK and abi_saved1, abi_saved1, a4 If a tracer attaches mid-syscall (e.g. using PTRACE_ATTACH on an Xtensa process currently blocked inside a system call), wouldn't the exit trace events be missed for most syscalls because abi_saved1 lacks the new flags, yet mysteriously be caught if the syscall happens to allocate a file descriptor (because TIF_FD_SLOTS is checked against the fresh TI_FLAGS)? Could we reload the fresh _TIF_WORK_MASK from thread_info here instead of relying on the stale abi_saved1 cache? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/20260915-work-fd-reserve-unify-folded-v1-0-4d5217d6b...@kernel.org?part=18
