Re: [PATCH RFC POC 18/50] xtensa: commit fds on syscall exit
From: sashiko-bot@kernel.org
Date: 2026-09-15 12:00:13
Also in:
bpf, dri-devel, io-uring, kexec, kvm, linux-alpha, linux-arm-kernel, linux-arm-msm, linux-fsdevel, linux-gpio, linux-hyperv, linux-m68k, linux-mips, linux-mm, linux-sh, linux-um, lkml, sparclinux, virtualization
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 [off-list ref] 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. [ ... ]
quoted hunk ↗ jump to hunk
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-4d5217d6b246@kernel.org?part=18