On Sat, 1 Feb 2025 15:35:13 +0100
Mathieu Desnoyers <[email protected]> wrote:
> On 2025-01-31 23:58, Steven Rostedt wrote:
>
> [...]
>
> > @@ -148,6 +160,18 @@ struct rseq {
> > */
> > __u32 mm_cid;
> >
> > + /*
> > + * The cr_counter is a way for user space to inform the kernel that
> > + * it is in a critical section. If bits 1-31 are set, then the
> > + * kernel may grant the thread a bit more time (but there is no
> > + * guarantee of how much time or if it is granted at all). If the
> > + * kernel does grant the thread extra time, it will set bit 0 to
> > + * inform user space that it has granted the thread more time and that
> > + * user space should call yield() as soon as it leaves its critical
>
> Does it specifically need to be yield(), or can it be just "entering
> the kernel" through any system call or trap ?
No it doesn't need to be yield. That just seemed like the obvious
system call to use. But any system call would force a schedule. We
could just optimize yield() though.
>
> [...]
>
> > diff --git a/kernel/rseq.c b/kernel/rseq.c
> > index 9de6e35fe679..b792e36a3550 100644
> > --- a/kernel/rseq.c
> > +++ b/kernel/rseq.c
> > @@ -339,6 +339,36 @@ void __rseq_handle_notify_resume(struct ksignal *ksig,
> > struct pt_regs *regs)
> > force_sigsegv(sig);
> > }
> >
> > +bool rseq_delay_resched(void)
> > +{
> > + struct task_struct *t = current;
> > + u32 flags;
> > +
> > + if (!t->rseq)
> > + return false;
> > +
> > + /* Make sure the cr_counter exists */
> > + if (current->rseq_len <= offsetof(struct rseq, cr_counter))
> > + return false;
>
> It would be clearer/more precise with < offsetofend(struct rseq, cr_counter)
Ah yeah, thanks!
-- Steve
