Re: [PATCH v15 08/11] arm64/ptrace: Define and use _TIF_SYSCALL_EXIT_WORK

[Ada Couprie Diaz]

On 25/06/2026 12:41, Jinjie Ruan wrote:
> On 6/24/2026 10:53 PM, Ada Couprie Diaz wrote:
> > On 11/05/2026 10:21, Jinjie Ruan wrote:
> > > Introduce _TIF_SYSCALL_EXIT_WORK to filter out entry-only flags
> > > during the syscall exit path. This aligns arm64 with the generic
> > > entry framework's SYSCALL_WORK_EXIT semantics.
> > >
> > > [Rationale]
> > > The current syscall exit path uses _TIF_SYSCALL_WORK to decide whether
> > > to invoke syscall_exit_work(). However, _TIF_SYSCALL_WORK includes
> > > flags that are only relevant during syscall entry:
> > >
> > > 1. _TIF_SECCOMP: Seccomp filtering (__secure_computing) only runs
> > >     on entry. There is no seccomp callback for syscall exit.
> > >
> > > 2. _TIF_SYSCALL_EMU: In PTRACE_SYSEMU mode, the syscall is
> > >     intercepted and skipped on entry. Since the syscall is never
> > >     executed, reporting a syscall exit stop is unnecessary.
> > >
> > > [Changes]
> > > - Define _TIF_SYSCALL_EXIT_WORK: A new mask containing only flags
> > >     requiring exit processing: _TIF_SYSCALL_TRACE, _TIF_SYSCALL_AUDIT,
> > >     and _TIF_SYSCALL_TRACEPOINT.
> > >
> > > - Update exit path: Use _TIF_SYSCALL_EXIT_WORK in
> > >     syscall_exit_to_user_mode_work() to avoid redundant calls to
> > >     audit and ptrace reporting when only entry-flags are set.
> > >
> > > - Cleanup: Remove the has_syscall_work() helper as it is no longer
> > >     needed. Direct flag comparison is now used to distinguish between
> > >     entry and exit work requirements.
> > >
> > > [Impact]
> > > audit_syscall_exit() and report_syscall_exit() will no longer be
> > > triggered for seccomp-only or emu-only syscalls. This matches the
> > > generic entry behavior and improves efficiency by skipping unnecessary
> > > exit processing.
> > >
> > > Cc: Mark Rutland <mark.rutland@xxxxxxx>
> > > Cc: Will Deacon <will@xxxxxxxxxx>
> > > Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
> > > Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>
> > > Reviewed-by: Yeoreum Yun <yeoreum.yun@xxxxxxx>
> > > Signed-off-by: Jinjie Ruan <ruanjinjie@xxxxxxxxxx>
> > > ---
> > Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@xxxxxxx>
> >
> > Definitely not related to this series, but it feels like this brings us
> > quite close to being able to switch to generic TIF flags as well :
> > only TIF_FOREIGN_PSTATE and TIF_MTE_ASYNC_FAULT
> > would need to be moved to the upper 16 bits,
> > with TIF_RESTORE_SIGMASK and TIF_MEMDIE freeing two slots there.
> >
> > Not sure how important the bit number changes would be and if any
> > of the extra generic bits require any arch support (TIF_POLLING_NRFLAG,
> > TIF_USER_RETURN_NOTIFY, TIF_RSEQ, TIF_HRTIMER_REARM)...
> >
> > But again, just thinking out loud !
> Hi Ada,
>
> You have incredible foresight! You are absolutely right that this series
> lays the perfect groundwork for switching arm64 to generic TIF flags
> (HAVE_GENERIC_TIF_BITS).
>
> I am happy to share that I have already implemented exactly what you
> described—including migrating the architecture-specific flags to the
> upper 16 bits and enabling the generic TIF infrastructure—in a separate,
> dedicated patch series.
>
> You can find the implementation and discussion here:
>
> https://lore.kernel.org/all/20260320104222.1381274-1-ruanjinjie@xxxxxxxxxx/
>
> Since that series directly builds on top of the cleanups and
> infrastructure introduced here, I plan to actively push it forward right
> after we get this core generic entry conversion landed.
>
> Thanks again for looking so far ahead and validating the direction!
>
> Best regards,
> Jinjie

Hi Jinjie,

Oh, neat, I evidently missed this series ;
glad you confirmed I was on the right track !

I am looking forward to seeing both those works merged then :)

Kind regards,
Ada