Re: [RFC] in-kernel rseq

[Mathieu Desnoyers]

On 2026-02-24 09:59, David Laight wrote:
> On Tue, 24 Feb 2026 08:48:03 -0500
> Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> 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).

No. The "code to setup rseq" is possibly a sequence of instructions
(or just one instruction) which ends with just a single store which
populates the rseq_cs pointer. It's OK to have the start address
immediately after that store.

Thanks,

Mathieu

--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com