Re: [PATCH v2] sched: set TIF_NEED_RESCHED before calling __trace_set_need_resched()

[Gabriele Monaco <gmonaco@redhat.com>]

On Mon, 2026-06-29 at 09:41 +0530, K Prateek Nayak wrote:
> Unrelated to changes here: This tracepoint seems to be missing from
> wake_up_idle_cpu() which modifies the ti->flags without taking the
> rq_lock.
> 
> A newly enqueued timer can race with the wakeup on idle CPU and you can
> see a wakeup + sched_switch without seeing a corresponding
> trace_sched_set_need_resched_tp() for the CPU.
> 
> Gabriele, is that a concern for RV?

Thanks Prateek for pointing this out. So as I'm understanding, we are missing
the tracepoint in that path, but even after putting it, this race might cause a
sched_switch to be visible concurrently or before the corresponding need_resched
for that CPU, right?

That's potentially an issue.

Currently the only model really relying on the need_resched event is nrp,
validating every kernel preemption has a corresponding need_resched set.
The scenario passing through wake_up_idle_cpu() is setting the flag on a CPU
that is idle (causing __schedule(SM_IDLE)), this doesn't count as a preemption
for the model. Or am I missing something?

That said, we should indeed add the tracepoint to that path and probably adapt
the monitor if that's making it fail indirectly.

Thanks,
Gabriele

> > +       if (need_ipi) {
> >                 if (tif == TIF_NEED_RESCHED)
> >                         smp_send_reschedule(cpu);
> >         } else {
> > --
> > 2.43.0
> >