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

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

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@efficios.com>

> 
> Thanks,
> 
>          tglx
> 
> 


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