On Thu, 23 Apr 2026 at 03:48, Jinjie Ruan [off-list ref] wrote:

On 4/23/2026 3:47 AM, Thomas Gleixner wrote:

quoted

On Wed, Apr 22 2026 at 19:11, Mark Rutland wrote:

quoted

On Wed, Apr 22, 2026 at 07:49:30PM +0200, Thomas Gleixner wrote:
Conceptually we just need to use syscall_enter_from_user_mode() and
irqentry_enter_from_user_mode() appropriately.

Right. I figured that out.

quoted

In practice, I can't use those as-is without introducing the exception
masking problems I just fixed up for irqentry_enter_from_kernel_mode(),
so I'll need to do some similar refactoring first.

See below.

quoted

I haven't paged everything in yet, so just to cehck, is there anything
that would behave incorrectly if current->rseq.event.user_irq were set
for syscall entry? IIUC it means we'll effectively do the slow path, and
I was wondering if that might be acceptable as a one-line bodge for
stable.

It might work, but it's trivial enough to avoid that. See below. That on
top of 6.19.y makes the selftests pass too.

This aligns with my thoughts when convert arm64 to generic syscall
entry. Currently, the arm64 entry code does not distinguish between IRQ
and syscall entries. It fails to call rseq_note_user_irq_entry() for IRQ
entries as the generic entry framework does, because arm64 uses
enter_from_user_mode() exclusively instead of
irqentry_enter_from_user_mode().

https://lore.kernel.org/all/20260320102620.1336796-10-ruanjinjie@huawei.com/ (local)

quoted

Thanks,

        tglx
---
 arch/arm64/kernel/entry-common.c |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c

@@ -58,6 +58,12 @@ static void noinstr exit_to_kernel_mode(
      irqentry_exit(regs, state);
 }

+static __always_inline void arm64_enter_from_user_mode_syscall(struct pt_regs *regs)
+{
+     enter_from_user_mode(regs);
+     mte_disable_tco_entry(current);
+}
+
 /*
  * Handle IRQ/context state management when entering from user mode.
  * Before this function is called it is not safe to call regular kernel code,

@@ -65,8 +71,8 @@ static void noinstr exit_to_kernel_mode(
  */
 static __always_inline void arm64_enter_from_user_mode(struct pt_regs *regs)
 {
-     enter_from_user_mode(regs);
-     mte_disable_tco_entry(current);
+     arm64_enter_from_user_mode_syscall(regs);
+     rseq_note_user_irq_entry();
 }

 /*

@@ -717,7 +723,7 @@ static void noinstr el0_brk64(struct pt_

 static void noinstr el0_svc(struct pt_regs *regs)
 {
-     arm64_enter_from_user_mode(regs);
+     arm64_enter_from_user_mode_syscall(regs);
      cortex_a76_erratum_1463225_svc_handler();
      fpsimd_syscall_enter();
      local_daif_restore(DAIF_PROCCTX);

@@ -869,7 +875,7 @@ static void noinstr el0_cp15(struct pt_r

 static void noinstr el0_svc_compat(struct pt_regs *regs)
 {
-     arm64_enter_from_user_mode(regs);
+     arm64_enter_from_user_mode_syscall(regs);
      cortex_a76_erratum_1463225_svc_handler();
      local_daif_restore(DAIF_PROCCTX);
      do_el0_svc_compat(regs);

+linux-man

This part of the rseq man page needs to be fixed as well I think. The
kernel no longer reliably provides clearing of rseq_cs on preemption,
right?

https://git.kernel.org/pub/scm/libs/librseq/librseq.git/tree/doc/man/rseq.2#n241

"and set to NULL by the kernel when it restarts an assembly
instruction sequence block,
as well as when the kernel detects that it is preempting or delivering
a signal outside of the range targeted by the rseq_cs."