Re: [RFC] in-kernel rseq

[David Laight <david.laight.linux@gmail.com>]

On Tue, 24 Feb 2026 08:48:03 -0500
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> On 2026-02-24 06:16, Heiko Carstens wrote:
> > On Mon, Feb 23, 2026 at 05:38:43PM +0100, Peter Zijlstra wrote:  
> >> This means, it needs to be woven into the asm... and I'm not that handy
> >> with arm64 asm.
> >>
> >> The pseudo code would be something like:
> >>
> >> 	current->sched_seq = &_R;
> >> 	...
> >>
> >> _start:  compute per cpu-addr
> >> 	 load addr
> >> 	 $OP
> >> _commit: store addr
> >>
> >> 	...
> >> 	current->sched_rseq = NULL;
> >>
> >>
> >> Then when preemption happens (from interrupt), the instruction pointer
> >> is 'simply' reset to _start and it tries again.  
> > 
> > I guess also on every interrupt, exception, and nmi current->sched_rseq needs
> > to be saved on entry, and restored on exit, since other contexts can make use
> > of this_cpu ops as well.  
> 
> If we do a design similar to userspace rseq, we'd abort the rseq
> critical section on interrupt, exception, nmi (by changing the pt_regs
> instruction pointer) rather than save/restore it. This is what
> userspace rseq does for signal handlers nesting on top of rseq critical
> sections.

Does that mean that 'start' would have to include the code to setup
the rseq? (rather than being after it as above).

	David

> 
> Thanks,
> 
> Mathieu
>