Re: [PATCH v9 2/3] sched: Move task_mm_cid_work to mm work_struct

[Gabriele Monaco <gmonaco@redhat.com>]

On Mon, 2025-02-24 at 15:50 -0500, Mathieu Desnoyers wrote:
> On 2025-02-24 08:28, Gabriele Monaco wrote:
> [...]
> > diff --git a/kernel/rseq.c b/kernel/rseq.c
> > index 2cb16091ec0ae..936863fe7eb37 100644
> > --- a/kernel/rseq.c
> > +++ b/kernel/rseq.c
> > @@ -419,6 +419,7 @@ void __rseq_handle_notify_resume(struct ksignal
> > *ksig, struct pt_regs *regs)
> >   	}
> >   	if (unlikely(rseq_update_cpu_node_id(t)))
> >   		goto error;
> > +	task_queue_mm_cid(t);
> 
> Given that task_queue_mm_cid() will be called quite frequently from
> __rseq_handle_notify_resume, perhaps it would be best to move at
> least
> the portion responsible for checks (including the time_before()) to
> include/linux/sched.h to eliminate a function call from the fast
> path.
> 
> 

Right, good idea. Thinking about that, task_queue_mm_cid checks a bit
more than the __rseq_handle_notify_resume.
As far as I understand, as long as we only call task_queue_mm_cid from
__rseq_handle_notify_resume, it won't ever be called from a kthread (I
assume the t->rseq implies t->mm and not PF_KTHREAD but also by
construction since it's called in return to user).

In short, considering we already check for PF_EXITING, the following is
just superfluous:

  if (!curr->mm || (curr->flags & (PF_EXITING | PF_KTHREAD)))
  	return;

and we could just keep the time_before check in
__rseq_handle_notify_resume, perhaps adding a t->mm check just to avoid
a perceived NULL pointer dereference, which seems not possible anyway.

Am I missing any corner case?

Thanks,
Gabriele