On Thu, Jul 02, 2026 at 01:34:34PM +0100, Will Deacon wrote:

On Wed, Jun 24, 2026 at 04:32:17PM +0100, Ada Couprie Diaz wrote:

quoted

On 11/05/2026 10:21, Jinjie Ruan wrote:

quoted

3. Architecture-Specific Hooks (asm/entry-common.h):
- Implement arch_ptrace_report_syscall_entry() and _exit() by
   porting the existing arm64 logic to the generic interface.

- Add arch_syscall_is_vdso_sigreturn() to asm/syscall.h to
   support Syscall User Dispatch (SUD).

Related to the above : I feel this is missing an important information.
Given that SUD is only controlled by `CONFIG_GENERIC_ENTRY`,
converting to generic entry _requires_ supporting SUD, so we do it here.
I think this would be important to mention, as I otherwise felt like this
change did not belong in this patch.

General question that follows : does it make sense to require an arch
to support Syscall User Dispatch to be able to convert to generic entry ?
(I assume not really, given that only `arch_syscall_is_vdso_sigreturn()` is
required on the arch side, but I am curious)

I think SUD should be separated from generic entry. I'm certainly keen
on the latter for arm64 and far less interested in the former. See this
series from Gregory:

https://lore.kernel.org/all/20260627205551.769684-1-gourry@gourry.net/ (local)

Agreed.

I see Gregory mentions some security concerns, and I think there are a
number of architecture-specific ABI concerns (e.g. how arm64's SVC
immediate gets handled), so I'm not keen to rush into supporting
SYSCALL_USER_DISPATCH.

I think what we want is:

(1) SYSCALL_USER_DISPATCH depends on GENERIC_ENTRY, as in Gregory's
    series.

(2) SYSCALL_USER_DISPATCH depends on some new
    ARCH_SUPPORTS_SYSCALL_USER_DISPATCH, such that it an architecture
    can implement GENERIC_ENTRY *without* being forced to implement
    SYSCALL_USER_DISPATCH.

(3) For now, we implement GENERIC_ENTRY for arm64 *without*
    ARCH_SUPPORTS_SYSCALL_USER_DISPATCH.

That way, we can focus on the core GENERIC_ENTRY support for arm64, and
address the inevitable fallout of that *before* we have to work through
all the concerns with SYSCALL_USER_DISPATCH.

Mark.