Currently, x86, Riscv, Loongarch use the Generic Entry which makes
maintainers' work easier and codes more elegant. arm64 has already
successfully switched to the Generic IRQ Entry in commit
b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
time to completely convert arm64 to Generic Entry.

The goal is to bring arm64 in line with other architectures that already
use the generic entry infrastructure, reducing duplicated code and
making it easier to share future changes in entry/exit paths, such as
"Syscall User Dispatch".

This patch set is rebased on "sched/core". And the performance
was measured on Kunpeng 920 using "perf bench basic syscall" with
"arm64.nopauth selinux=0 audit=1".

On the basis of optimizing syscall_get_arguments()[1], el0_svc_common(),
the performance are below:

| Metric     | W/O Generic Entry | With Generic Entry opt| Change |
| ---------- | ----------------- | ------------------    | ------ |
| Total time | 2.487 [sec]       | 2.264 [sec]           | ↓9.0% |
| usecs/op   | 0.248780          | 0.226481              | ↓9.0% |
| ops/sec    | 4,019,620         | 4,415,383             | ↑9.8% |

Therefore, after the optimization, ARM64 System Call performance improved
by approximately 9%.

It was tested ok with following test cases on kunpeng920 and QEMU
virt platform:
 - Perf tests.
 - Different `dynamic preempt` mode switch.
 - Pseudo NMI tests.
 - Stress-ng CPU stress test.
 - Hackbench stress test.
 - MTE test case in Documentation/arch/arm64/memory-tagging-extension.rst
   and all test cases in tools/testing/selftests/arm64/mte/*.
 - "sud" selftest testcase.
 - get_set_sud, get_syscall_info, set_syscall_info, peeksiginfo
   in tools/testing/selftests/ptrace.
 - breakpoint_test_arm64 in selftests/breakpoints.
 - syscall-abi and ptrace in tools/testing/selftests/arm64/abi
 - fp-ptrace, sve-ptrace, za-ptrace in selftests/arm64/fp.
 - vdso_test_getrandom in tools/testing/selftests/vDSO
 - Strace tests.

The test QEMU configuration is as follows:

	qemu-system-aarch64 \
		-M virt,gic-version=3,virtualization=on,mte=on \
		-cpu max,pauth-impdef=on \
		-kernel Image \
		-smp 8,sockets=1,cores=4,threads=2 \
		-m 512m \
		-nographic \
		-no-reboot \
		-device virtio-rng-pci \
		-append "root=/dev/vda rw console=ttyAMA0 kgdboc=ttyAMA0,115200 \
			earlycon preempt=voluntary irqchip.gicv3_pseudo_nmi=1" \
		-drive if=none,file=images/rootfs.ext4,format=raw,id=hd0 \
		-device virtio-blk-device,drive=hd0 \

[1]: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm/+/89bf683c9507c280e20c3e17b4ea15e19696ed63%5E%21/#F0

Changes in v12:
- Rebased on "sched/core", so remove the four generic entry patches.
- Move "Expand secure_computing() in place" and "Use syscall_get_arguments()
  helper" patch forward, which will group all non-functional cleanups
  at the front.
- Adjust the explanation for moving rseq_syscall() before audit_syscall_exit().
- Link to v11: https://lore.kernel.org/all/20260128031934.3906955-1-ruanjinjie@huawei.com/

Changes in v11:
- Remove unused syscall in syscall_trace_enter().
- Update and provide a detailed explanation of the differences after
  moving rseq_syscall() before audit_syscall_exit().
- Rebased on arm64 (for-next/entry), and remove the first applied 3 patchs.
- syscall_exit_to_user_mode_work() for arch reuse instead of adding
  new syscall_exit_to_user_mode_work_prepare() helper.
- Link to v10: https://lore.kernel.org/all/20251222114737.1334364-1-ruanjinjie@huawei.com/

Changes in v10:
- Rebased on v6.19-rc1, rename syscall_exit_to_user_mode_prepare() to
  syscall_exit_to_user_mode_work_prepare() to avoid conflict.
- Also inline syscall_trace_enter().
- Support aarch64 for sud_benchmark.
- Update and correct the commit message.
- Add Reviewed-by.
- Link to v9: https://lore.kernel.org/all/20251204082123.2792067-1-ruanjinjie@huawei.com/

Changes in v9:
- Move "Return early for ptrace_report_syscall_entry() error" patch ahead
  to make it not introduce a regression.
- Not check _TIF_SECCOMP/SYSCALL_EMU for syscall_exit_work() in
  a separate patch.
- Do not report_syscall_exit() for PTRACE_SYSEMU_SINGLESTEP in a separate
  patch.
- Add two performance patch to improve the arm64 performance.
- Add Reviewed-by.
- Link to v8: https://lore.kernel.org/all/20251126071446.3234218-1-ruanjinjie@huawei.com/

Changes in v8:
- Rename "report_syscall_enter()" to "report_syscall_entry()".
- Add ptrace_save_reg() to avoid duplication.
- Remove unused _TIF_WORK_MASK in a standalone patch.
- Align syscall_trace_enter() return value with the generic version.
- Use "scno" instead of regs->syscallno in el0_svc_common().
- Move rseq_syscall() ahead in a standalone patch to clarify it clearly.
- Rename "syscall_trace_exit()" to "syscall_exit_work()".
- Keep the goto in el0_svc_common().
- No argument was passed to __secure_computing() and check -1 not -1L.
- Remove "Add has_syscall_work() helper" patch.
- Move "Add syscall_exit_to_user_mode_prepare() helper" patch later.
- Add miss header for asm/entry-common.h.
- Update the implementation of arch_syscall_is_vdso_sigreturn().
- Add "ARCH_SYSCALL_WORK_EXIT" to be defined as "SECCOMP | SYSCALL_EMU"
  to keep the behaviour unchanged.
- Add more testcases test.
- Add Reviewed-by.
- Update the commit message.
- Link to v7: https://lore.kernel.org/all/20251117133048.53182-1-ruanjinjie@huawei.com/

Jinjie Ruan (12):
  arm64: Remove unused _TIF_WORK_MASK
  arm64/ptrace: Split report_syscall()
  arm64/ptrace: Return early for ptrace_report_syscall_entry() error
  arm64/ptrace: Refactor syscall_trace_enter/exit()
  arm64/ptrace: Expand secure_computing() in place
  arm64/ptrace: Use syscall_get_arguments() helper
  arm64: ptrace: Move rseq_syscall() before audit_syscall_exit()
  arm64: syscall: Rework el0_svc_common()
  arm64/ptrace: Not check _TIF_SECCOMP/SYSCALL_EMU for
    syscall_exit_work()
  arm64/ptrace: Do not report_syscall_exit() for
    PTRACE_SYSEMU_SINGLESTEP
  arm64: entry: Convert to generic entry
  arm64: Inline el0_svc_common()

kemal (1):
  selftests: sud_test: Support aarch64

 arch/arm64/Kconfig                            |  2 +-
 arch/arm64/include/asm/entry-common.h         | 76 +++++++++++++++
 arch/arm64/include/asm/syscall.h              | 19 +++-
 arch/arm64/include/asm/thread_info.h          | 22 +----
 arch/arm64/kernel/debug-monitors.c            |  7 ++
 arch/arm64/kernel/ptrace.c                    | 94 -------------------
 arch/arm64/kernel/signal.c                    |  2 +-
 arch/arm64/kernel/syscall.c                   | 29 ++----
 .../syscall_user_dispatch/sud_benchmark.c     |  2 +-
 .../syscall_user_dispatch/sud_test.c          |  4 +
 10 files changed, 115 insertions(+), 142 deletions(-)

-- 
2.34.1

On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> maintainers' work easier and codes more elegant. arm64 has already
> successfully switched to the Generic IRQ Entry in commit
> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> time to completely convert arm64 to Generic Entry.
>
> The goal is to bring arm64 in line with other architectures that already
> use the generic entry infrastructure, reducing duplicated code and
> making it easier to share future changes in entry/exit paths, such as
> "Syscall User Dispatch".
>
> This patch set is rebased on "sched/core". And the performance

Why are you using sched/core, which contains a lot of unrelated
changes. core/entry is the one which has the prerequisites and nothing
else....

On 2026/2/3 22:16, Thomas Gleixner wrote:
> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>> maintainers' work easier and codes more elegant. arm64 has already
>> successfully switched to the Generic IRQ Entry in commit
>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>> time to completely convert arm64 to Generic Entry.
>>
>> The goal is to bring arm64 in line with other architectures that already
>> use the generic entry infrastructure, reducing duplicated code and
>> making it easier to share future changes in entry/exit paths, such as
>> "Syscall User Dispatch".
>>
>> This patch set is rebased on "sched/core". And the performance
> 
> Why are you using sched/core, which contains a lot of unrelated
> changes. core/entry is the one which has the prerequisites and nothing
> else....

By the way，it looks like core/entry and arm64 for-next/entry have
diverged: the first three patches of this series are already in arm64
for-next/entry but missing from core/entry.
Perhaps the two branches should be reconciled so that both contain the
same baseline.

> 
> 

On Wed, Feb 04 2026 at 09:28, Jinjie Ruan wrote:
> On 2026/2/3 22:16, Thomas Gleixner wrote:
>> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
>>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>>> maintainers' work easier and codes more elegant. arm64 has already
>>> successfully switched to the Generic IRQ Entry in commit
>>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>>> time to completely convert arm64 to Generic Entry.
>>>
>>> The goal is to bring arm64 in line with other architectures that already
>>> use the generic entry infrastructure, reducing duplicated code and
>>> making it easier to share future changes in entry/exit paths, such as
>>> "Syscall User Dispatch".
>>>
>>> This patch set is rebased on "sched/core". And the performance
>> 
>> Why are you using sched/core, which contains a lot of unrelated
>> changes. core/entry is the one which has the prerequisites and nothing
>> else....
>
> By the way，it looks like core/entry and arm64 for-next/entry have
> diverged: the first three patches of this series are already in arm64
> for-next/entry but missing from core/entry.
> Perhaps the two branches should be reconciled so that both contain the
> same baseline.

The first three patches of this series are ARM specific and have nothing
to do with the queued core/entry changes in tip. They are independent of
each other and these three ARM64 changes have no business in my tree.

If the ARM64 folks want to apply the rest of your series then they have
to pull the core/entry branch into their for-next/core branch first so
the whole thing builds.

But given that the merge window opens on sunday, this is probably moot
anyway and the rest of this series can go on top of rc1 in the ARM64
tree w/o any further complications.

Thanks,

        tglx

On 2026/2/4 18:39, Thomas Gleixner wrote:
> On Wed, Feb 04 2026 at 09:28, Jinjie Ruan wrote:
>> On 2026/2/3 22:16, Thomas Gleixner wrote:
>>> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
>>>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>>>> maintainers' work easier and codes more elegant. arm64 has already
>>>> successfully switched to the Generic IRQ Entry in commit
>>>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>>>> time to completely convert arm64 to Generic Entry.
>>>>
>>>> The goal is to bring arm64 in line with other architectures that already
>>>> use the generic entry infrastructure, reducing duplicated code and
>>>> making it easier to share future changes in entry/exit paths, such as
>>>> "Syscall User Dispatch".
>>>>
>>>> This patch set is rebased on "sched/core". And the performance
>>>
>>> Why are you using sched/core, which contains a lot of unrelated
>>> changes. core/entry is the one which has the prerequisites and nothing
>>> else....
>>
>> By the way，it looks like core/entry and arm64 for-next/entry have
>> diverged: the first three patches of this series are already in arm64
>> for-next/entry but missing from core/entry.
>> Perhaps the two branches should be reconciled so that both contain the
>> same baseline.
> 
> The first three patches of this series are ARM specific and have nothing
> to do with the queued core/entry changes in tip. They are independent of
> each other and these three ARM64 changes have no business in my tree.
> 
> If the ARM64 folks want to apply the rest of your series then they have
> to pull the core/entry branch into their for-next/core branch first so
> the whole thing builds.
> 
> But given that the merge window opens on sunday, this is probably moot
> anyway and the rest of this series can go on top of rc1 in the ARM64
> tree w/o any further complications.

Thanks for the clear explanation, many thanks as well for the extensive
review work and the prompt replies on the generic entry changes.

Regards,
Jinjie

> 
> Thanks,
> 
>         tglx
> 

On Wed, Feb 04, 2026 at 11:39:34AM +0100, Thomas Gleixner wrote:
> On Wed, Feb 04 2026 at 09:28, Jinjie Ruan wrote:
> > On 2026/2/3 22:16, Thomas Gleixner wrote:
> >> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
> >>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
> >>> maintainers' work easier and codes more elegant. arm64 has already
> >>> successfully switched to the Generic IRQ Entry in commit
> >>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
> >>> time to completely convert arm64 to Generic Entry.
> >>>
> >>> The goal is to bring arm64 in line with other architectures that already
> >>> use the generic entry infrastructure, reducing duplicated code and
> >>> making it easier to share future changes in entry/exit paths, such as
> >>> "Syscall User Dispatch".
> >>>
> >>> This patch set is rebased on "sched/core". And the performance
> >> 
> >> Why are you using sched/core, which contains a lot of unrelated
> >> changes. core/entry is the one which has the prerequisites and nothing
> >> else....
> >
> > By the way，it looks like core/entry and arm64 for-next/entry have
> > diverged: the first three patches of this series are already in arm64
> > for-next/entry but missing from core/entry.
> > Perhaps the two branches should be reconciled so that both contain the
> > same baseline.
> 
> The first three patches of this series are ARM specific and have nothing
> to do with the queued core/entry changes in tip. They are independent of
> each other and these three ARM64 changes have no business in my tree.
> 
> If the ARM64 folks want to apply the rest of your series then they have
> to pull the core/entry branch into their for-next/core branch first so
> the whole thing builds.
> 
> But given that the merge window opens on sunday, this is probably moot
> anyway and the rest of this series can go on top of rc1 in the ARM64
> tree w/o any further complications.

Yup, the rest of the series (beyond what we've both queued) also needs
some more review so this is all post -rc1 material.

In the meantime, thanks for picking up the generic bits.

Cheers,

Will

On 2026/2/4 20:07, Will Deacon wrote:
> On Wed, Feb 04, 2026 at 11:39:34AM +0100, Thomas Gleixner wrote:
>> On Wed, Feb 04 2026 at 09:28, Jinjie Ruan wrote:
>>> On 2026/2/3 22:16, Thomas Gleixner wrote:
>>>> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
>>>>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>>>>> maintainers' work easier and codes more elegant. arm64 has already
>>>>> successfully switched to the Generic IRQ Entry in commit
>>>>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>>>>> time to completely convert arm64 to Generic Entry.
>>>>>
>>>>> The goal is to bring arm64 in line with other architectures that already
>>>>> use the generic entry infrastructure, reducing duplicated code and
>>>>> making it easier to share future changes in entry/exit paths, such as
>>>>> "Syscall User Dispatch".
>>>>>
>>>>> This patch set is rebased on "sched/core". And the performance
>>>>
>>>> Why are you using sched/core, which contains a lot of unrelated
>>>> changes. core/entry is the one which has the prerequisites and nothing
>>>> else....
>>>
>>> By the way，it looks like core/entry and arm64 for-next/entry have
>>> diverged: the first three patches of this series are already in arm64
>>> for-next/entry but missing from core/entry.
>>> Perhaps the two branches should be reconciled so that both contain the
>>> same baseline.
>>
>> The first three patches of this series are ARM specific and have nothing
>> to do with the queued core/entry changes in tip. They are independent of
>> each other and these three ARM64 changes have no business in my tree.
>>
>> If the ARM64 folks want to apply the rest of your series then they have
>> to pull the core/entry branch into their for-next/core branch first so
>> the whole thing builds.
>>
>> But given that the merge window opens on sunday, this is probably moot
>> anyway and the rest of this series can go on top of rc1 in the ARM64
>> tree w/o any further complications.
> 
> Yup, the rest of the series (beyond what we've both queued) also needs
> some more review so this is all post -rc1 material.

Sounds good; I’m looking forward to more expert eyes on the remaining
patches once -rc1 is out.

> 
> In the meantime, thanks for picking up the generic bits.
> 
> Cheers,
> 
> Will
> 

On 2026/2/3 22:16, Thomas Gleixner wrote:
> On Tue, Feb 03 2026 at 21:37, Jinjie Ruan wrote:
>> Currently, x86, Riscv, Loongarch use the Generic Entry which makes
>> maintainers' work easier and codes more elegant. arm64 has already
>> successfully switched to the Generic IRQ Entry in commit
>> b3cf07851b6c ("arm64: entry: Switch to generic IRQ entry"), it is
>> time to completely convert arm64 to Generic Entry.
>>
>> The goal is to bring arm64 in line with other architectures that already
>> use the generic entry infrastructure, reducing duplicated code and
>> making it easier to share future changes in entry/exit paths, such as
>> "Syscall User Dispatch".
>>
>> This patch set is rebased on "sched/core". And the performance
> 
> Why are you using sched/core, which contains a lot of unrelated
> changes. core/entry is the one which has the prerequisites and nothing
> else....

Sorry for misunderstanding your v11 reply—however, these patches can
still be applied directly to the core/entry branch.

Thanks,
Jinjie
> 
>