Re: [patch V4 15/36] rseq: Record interrupt from user space

[Mathieu Desnoyers]

On 2025-09-09 10:17, Thomas Gleixner wrote:
> On Tue, Sep 09 2025 at 09:53, Mathieu Desnoyers wrote:
> > >    static __always_inline void rseq_exit_to_user_mode(void)
> > >    {
> > > -	if (IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
> > > -		if (WARN_ON_ONCE(current->rseq.event.has_rseq &&
> > > -				 current->rseq.event.events))
> > > -			current->rseq.event.events = 0;
> > > -	}
> > > +	struct rseq_event *ev = &current->rseq.event;
> > > +
> > > +	if (IS_ENABLED(CONFIG_DEBUG_RSEQ))
> > > +		WARN_ON_ONCE(ev->sched_switch);
> >
> > OK. Now I'm confused.
> >
> > It is perfectly legal to issue a system call from userspace as long
> > as it's not from within an rseq critical section.
> >
> > That system call can be scheduled out, and can set the ev->sched_switch.
> >
> > This would cause the rseq_exit_to_user_mode from system call to
> > hit this.
> >
> > What is disallowed is only issuing a system call from a rseq critical
> > section. The other parts of rseq (updates of cpu id and mm cid) still
> > have to happen when returning from a system call.
> >
> > What am I missing ?
>
> The fact that any setting of ev->sched_switch has to be handled on the
> way out independent of user interrupt or not as MM CID can change
> obviously.
>
> This is not any different from the state before this patch. Just that it
> now only looks at sched_switch instead of the full event as that might
> contain a set user_irq bit w/o sched_switch being set, no?

OK, so this is called after the events were handled, and this is just
a sanity check.

Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>

> Thanks,
>
>          tglx


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