On 2026/1/29 20:06, Kevin Brodsky wrote:
> On 28/01/2026 04:19, Jinjie Ruan wrote:
>> commit a9f3a74a29af ("entry: Provide generic syscall exit function")
>> introduce generic syscall exit function and call rseq_syscall()
>> before audit_syscall_exit() and arch_syscall_exit_tracehook().
>>
>> And commit b74406f37737 ("arm: Add syscall detection for restartable
>> sequences") add rseq support for arm32, which also call rseq_syscall()
>> before audit_syscall_exit() and tracehook_report_syscall().
>>
>> However, commit 409d5db49867c ("arm64: rseq: Implement backend rseq
>> calls and select HAVE_RSEQ") implement arm64 rseq and call
>> rseq_syscall() after audit_syscall_exit() and tracehook_report_syscall().
>> So compared to the generic entry and arm32 code, arm64 calls
>> rseq_syscall() a bit later.
>>
>> But as commit b74406f37737 ("arm: Add syscall detection for restartable
>> sequences") said, syscalls are not allowed inside restartable sequences,
>> so should call rseq_syscall() at the very beginning of system call
>> exiting path for CONFIG_DEBUG_RSEQ=y kernel. This could help us to detect
>> whether there is a syscall issued inside restartable sequences.
>>
>> As for the impact of raising SIGSEGV via rseq_syscall(), it makes no
>> practical difference to signal delivery because signals are processed
>> in arm64_exit_to_user_mode() at the very end.
>>
>> As for the "regs", rseq_syscall() only checks and update
>> instruction_pointer(regs), ptrace can not modify the "pc" on syscall exit
>> path but 'only changes the return value', so calling rseq_syscall()
>> before or after ptrace_report_syscall_exit() makes no difference.
>
> Let's update this as discussed on v10 - PC can be modified when
> ptrace_report_syscall_exit() is called.
Should rseq see the PC modified by ptrace on the syscall exit path?
If the PC modified by ptrace happens to fall inside the user-space rseq
critical section, is that reasonable? If so, doesn't that make the order
of rseq and ptrace syscall exit in generic entry incorrect?
Could we have an rseq expert join the discussion — Thomas, what is your
opinion?
>
>> And audit_syscall_exit() only checks the return value (x0 for arm64),
>> so calling rseq_syscall() before or after audit syscall exit makes
>> no difference. trace_sys_exit() only uses syscallno and the return value,
>> so calling rseq_syscall() before or after trace_sys_exit() also makes
>> no difference.
>>
>> In preparation for moving arm64 over to the generic entry code, move
>> rseq_syscall() ahead before audit_syscall_exit().
>>
>> No functional changes.
>
> And naturally this is not the case.
>
> - Kevin
>
>> Reviewed-by: Kevin Brodsky <[email protected]>
>> Signed-off-by: Jinjie Ruan <[email protected]>
>> ---
>> arch/arm64/kernel/ptrace.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>> index 9f9aa3087c09..785280c76317 100644
>> --- a/arch/arm64/kernel/ptrace.c
>> +++ b/arch/arm64/kernel/ptrace.c
>> @@ -2443,6 +2443,8 @@ int syscall_trace_enter(struct pt_regs *regs, unsigned
>> long flags)
>>
>> void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
>> {
>> + rseq_syscall(regs);
>> +
>> audit_syscall_exit(regs);
>>
>> if (flags & _TIF_SYSCALL_TRACEPOINT)
>> @@ -2450,8 +2452,6 @@ void syscall_trace_exit(struct pt_regs *regs, unsigned
>> long flags)
>>
>> if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP))
>> report_syscall_exit(regs);
>> -
>> - rseq_syscall(regs);
>> }
>>
>> /*
>
